From Robert.Glassey@nmp.nokia.com Wed Oct 02 06:56:05 1996
Received: from noknic.nokia.com (noknic.nokia.com [131.228.6.10]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id GAA17030 for <hfsig@tapr.org>; Wed, 2 Oct 1996 06:56:03 -0500 (CDT)
From: Robert.Glassey@nmp.nokia.com
Received: from samail01.nmp.nokia.com (samail01.nmp.nokia.com [131.228.240.6]) by noknic.nokia.com (8.6.9/8.6.9) with ESMTP id NAA02670 for <hfsig@tapr.org>; Wed, 2 Oct 1996 13:55:20 +0200
Received: from  by samail01.nmp.nokia.com with SMTP
	(1.37.109.16/16.2) id AA274567345; Wed, 2 Oct 1996 14:55:45 +0300
X-Openmail-Hops: 2
Date: Wed, 2 Oct 96 12:03:34 +0100
Message-Id: <H00002920283aab6@MHS>
Subject: RELEASE OF BTL 1.0
Mime-Version: 1.0
To: hfsig@tapr.org
Content-Type: text/plain; charset=ISO-8859-1; name="RELEASE"
Content-Transfer-Encoding: 7bit


                        Blaster TeLetype V1.0
                       ~~~~~~~~~~~~~~~~~~~~~~~

Finally released and now available in the upload directory at URL:

ftp://ftp.tapr.org/tapr/SIG/hfsig/upload/btl10.zip

Blaster TeLetype (BTL) is my DSP RTTY demodulator package using the
Sound Blaster card (1.0 or greater) and a 386DX or greater IBM PC or
compatible.

BTL is FREE for amateur use. But volantary registration is encouraged to
support the ongoing developemnt of this program into a fully featured
DSP multimode modem using only a PC and sound card.


                     B T L   1.0   F E A T U R E S
                    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

o  RX only RTTY demodualtion
o  Fully adjustable centre frequency, with presets for standard tone
   sets.
o  Fully adjustable frequency shift, 100Hz to 3000Hz, with easy presets.
o  Fully adjustable baud rate, 25 to 200 Baud
o  USB or LSB default Mark/Space polarity
o  RXR Mark/Space tone reversal
o  NAR Narrow/Wide tone filter option
o  UNS Unshift on Space
o  LOG Save received text to a log file
o  43/50 line mode
o  Manually forced letters or figures shift
o  Manually forced New Line on demod screen
o  Demodulation pause key (Hold)
o  On screen tuning and level indicators
o  User adjustable Soundblaster input level settings and input selection
o  User adjustable defaults and input levels saved in config file
o  Support for Sound Blasters version 1.0 through AWE32.
o  Sound Blaster parameter validation
o  Extensive on-Line HELP!!
o  Bright Colours!


Download and Enjoy!

Many thanks to the many HFSIG'er who have beta tested this software over
the past months. I an now fairly confident BTL is stable and works on
the vast majority of soundblasters, PC's and compatibles. No gaurantees
though, its free after all!

A description of the inards of BTL will follow soon.

Cheers,

Rob, G0VTQ

From lylej@azstarnet.com Wed Oct 02 09:35:27 1996
Received: from mailhost.azstarnet.com (mailhost.azstarnet.com [169.197.1.8]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id JAA22205 for <hfsig@tapr.org>; Wed, 2 Oct 1996 09:35:25 -0500 (CDT)
Received: from tomswift2 (usr7ip57.azstarnet.com [169.197.8.57]) by mailhost.azstarnet.com (8.7.6/8.7.6) with SMTP id HAA24892 for <hfsig@tapr.org>; Wed, 2 Oct 1996 07:34:23 -0700 (MST)
Date: Wed, 2 Oct 1996 07:34:23 -0700 (MST)
Message-Id: <1.5.4.32.19961002073412.003524b4@azstarnet.com>
X-Sender: lylej@azstarnet.com
X-Mailer: Windows Eudora Light Version 1.5.4 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: hfsig@tapr.org
From: Lyle Johnson <lylej@azstarnet.com>
Subject: Development Environment

A couple years ago we bought the development system for the Star
Semiconductor SPROC chips.  OF course, once we had the product designed and
debugged, Star went belly up and we had to switch horses :-)

The development system they sold consisted of a schematic interface (OrCAD).
The various building blocks in the schematic library were associatd with
pre-written and optimized code in both subroutine and in-line formats.
Arguments needed by the routines were entered onto the schematic as fields
(much as a resistor could have a "value" and a "tolerance", a signal
generaotr could have a "frequency" and an "amplitude."

Once you "sketched" your design, you'd tell the schematic capture tools to
output its "netlist", then turn the results of that loose on the "compiler"
which would look for syntax problems and, once it was happy, it would chrun
on the result and provide you with the otuptu code.  You'd then download
this into the development lab and start debugging the design rather than the
details.

I guess loosely it is like using a high level language rather than assembler
to get things done.

Of course, the SPORC chip had superb real-time debugging characteristics,
but that is another story.

I'm wondering if anyone on this sig has the knowledge and inclination to do
something like this?  Perhaps those that are good DSP coders could write the
various "modules" and someone strong in compiler knowledge could write the
tool that took the "netlist" and created the source module to run through
the mfr's assembler/linker/etc.

I could be persuaded to work on schematic symbols and so forth for at least
one or two popular (inexpensive?) windows-based tools (like the one from
Ivex, for example).

Does this sort of idea appeal to anyone else?  IF so, which DSP chip(s)?  I
tend to lean towards the ADSP-2181, but then TAPR is sponsoring the DSP56002
development board buy, so that may make more sense to target...

Cheers,

Lyle

From jsanford@infi.net Wed Oct 02 10:58:12 1996
Received: from mh004.infi.net (mh004.infi.net [198.22.1.119]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id KAA24869 for <hfsig@tapr.org>; Wed, 2 Oct 1996 10:58:10 -0500 (CDT)
Received: from PENTIUM by mh004.infi.net with SMTP 
	(Infinet-S-3.3) id LAA08624; Wed, 2 Oct 1996 11:58:17 -0400 (EDT)
Message-ID: <3252911B.5746@infi.net>
Date: Wed, 02 Oct 1996 11:58:19 -0400
From: Jim Sanford <jsanford@infi.net>
Reply-To: wb4gcs@amsat.org
Organization: WB4GCS
X-Mailer: Mozilla 3.0 (Win16; U)
MIME-Version: 1.0
To: hfsig@tapr.org
Subject: Re: [HFSIG:1551] Development Environment
References: <1.5.4.32.19961002073412.003524b4@azstarnet.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Lyle Johnson wrote:
> 
> A couple years ago we bought the development system for the Star
> Semiconductor SPROC chips.  OF course, once we had the product designed and
> debugged, Star went belly up and we had to switch horses :-)
> 
> The development system they sold consisted of a schematic interface (OrCAD).
> The various building blocks in the schematic library were associatd with
> pre-written and optimized code in both subroutine and in-line formats.
> Arguments needed by the routines were entered onto the schematic as fields
> (much as a resistor could have a "value" and a "tolerance", a signal
> generaotr could have a "frequency" and an "amplitude."
> 
> Once you "sketched" your design, you'd tell the schematic capture tools to
> output its "netlist", then turn the results of that loose on the "compiler"
> which would look for syntax problems and, once it was happy, it would chrun
> on the result and provide you with the otuptu code.  You'd then download
> this into the development lab and start debugging the design rather than the
> details.
> 
> I guess loosely it is like using a high level language rather than assembler
> to get things done.
> 
> Of course, the SPORC chip had superb real-time debugging characteristics,
> but that is another story.
> 
> I'm wondering if anyone on this sig has the knowledge and inclination to do
> something like this?  Perhaps those that are good DSP coders could write the
> various "modules" and someone strong in compiler knowledge could write the
> tool that took the "netlist" and created the source module to run through
> the mfr's assembler/linker/etc.
> 
> I could be persuaded to work on schematic symbols and so forth for at least
> one or two popular (inexpensive?) windows-based tools (like the one from
> Ivex, for example).
> 
> Does this sort of idea appeal to anyone else?  IF so, which DSP chip(s)?  I
> tend to lean towards the ADSP-2181, but then TAPR is sponsoring the DSP56002
> development board buy, so that may make more sense to target...
> 
> Cheers,
> 
> Lyle
Lyle:
I, too, lean toward the ADSP chips and think you  have a GREAT idea.
Wish I were smart enough to do it .. . . ..

Good luck1

73, Jim
wb4gcs@amsat.org

From jbloom@arrl.org Wed Oct 02 12:30:30 1996
Received: from mgate.arrl.org (root@mgate.arrl.org [205.217.201.2]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id MAA28650 for <hfsig@tapr.org>; Wed, 2 Oct 1996 12:30:27 -0500 (CDT)
Received: from smtp_gw by mgate.arrl.org with smtp
	(Smail3.1.29.1 #9) id m0v8V7q-000f4iC; Wed, 2 Oct 96 13:30 EDT
Message-Id: <m0v8V7q-000f4iC@mgate.arrl.org>
Priority: urgent
Date: Wed, 2 Oct 1996 14:28:00 -0400
From: "Bloom, Jon,  KE3Z" <jbloom@arrl.org>
Subject: RE: [HFSIG:1551] Development Environment
To: "'hfsig@tapr.org'" <hfsig@tapr.org>
X-Mailer: Worldtalk (NetConnex V4.00a)/MIME


Lyle wrote:
> A couple years ago we bought the development system for the Star
> Semiconductor SPROC chips.  OF course, once we had the product designed   
and
> debugged, Star went belly up and we had to switch horses :-)

That's why they call it the "bleeding edge." :-)

> I'm wondering if anyone on this sig has the knowledge and inclination   
to do
> something like this?  Perhaps those that are good DSP coders could   
write the
> various "modules" and someone strong in compiler knowledge could write   
the
> tool that took the "netlist" and created the source module to run   
through
> the mfr's assembler/linker/etc.

I've thought about something along these lines from time to time but have   
never
had the time to do anything about it--and still don't. (Read: I'm *not*
volunteering.)

> Does this sort of idea appeal to anyone else?  IF so, which DSP   
chip(s)?  I
> tend to lean towards the ADSP-2181, but then TAPR is sponsoring the   
DSP56002
> development board buy, so that may make more sense to target...

I think it would at least be worth thinking about doing it in a modular
enough way that it could support different processors by, for example,
loading a processor-specific DLL if it's a Windows app. Doing it that
way would make it more complex initially but much more useful in the
long run.

It also would make sense to have some platform-specific capabilities.
If, for example, you are generating code for a TMS320C26, it would be
nice if the program knew enough about the differences between the
DSP-93 and the TI DSK to insert the needed glue code to generate a
complete loadable program for the target platform.

It also would be neat if the program could do a simulation of the   
designed
system, as well as generating processor code. (And since I'm not
volunteering to do the work, it costs me nothing to make the suggestion!)
At first blush, this would seem to be a relatively easy addition to the
scheme.

It seems to me that this could be a pretty straightforward project on the
first cut, particularly if you didn't worry too much about generating
optimal DSP code for the particular target processor, but just strung
together canned chunks of code to implement particular DSP functions
(FIR and IIR filters, for example). Whenever I've thought about this in
the past it was always the graphical front-end that made me shy away
from pursuing it, but I think Lyle has a good idea of a way around that.
 --
Jon Bloom, KE3Z
jbloom@arrl.org

From danny.kohn@systematik.se Wed Oct 02 15:00:16 1996
Received: from mailbox.swip.net (mailbox.swip.net [193.12.122.1]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id PAA05153 for <hfsig@tapr.org>; Wed, 2 Oct 1996 15:00:15 -0500 (CDT)
Received: from dialup99-3-1.swipnet.se (dialup104-2-1.swipnet.se [130.244.104.21]) 
          by mailbox.swip.net (8.7.6swip/8.7.3) with SMTP 
          id VAA19290 for <hfsig@tapr.org>; 
          Wed, 2 Oct 1996 21:59:57 +0200 (MET DST)
Received: by dialup99-3-1.swipnet.se with Microsoft Mail
	id <01BBB0AD.07A7F860@dialup99-3-1.swipnet.se>; Wed, 2 Oct 1996 21:59:48 +0200
Message-ID: <01BBB0AD.07A7F860@dialup99-3-1.swipnet.se>
From: Danny Kohn <danny.kohn@systematik.se>
To: "'hfsig@tapr.org'" <hfsig@tapr.org>
Subject: RE: [HFSIG:1553] RE: Development Environment
Date: Wed, 2 Oct 1996 21:18:55 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

On  den 2 oktober 1996 14:42, Bloom, Jon,  KE3Z[SMTP:jbloom@arrl.org] =
wrote:

> Whenever I've thought about this in
> the past it was always the graphical front-end that made me shy away
> from pursuing it, but I think Lyle has a good idea of a way around =
that.

Is the ARRL Radio designer not a viable solution to this or is it not
advanced enough?

H=E4lsningar / Regards
Danny Kohn - SM0NBJ
Utvecklingskonsult / Development Consultant
Systematik Consuliting AB - www.systematik.se - +46 708 140 300

From lylej@azstarnet.com Wed Oct 02 20:09:44 1996
Received: from mailhost.azstarnet.com (mailhost.azstarnet.com [169.197.1.8]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id UAA15472 for <hfsig@tapr.org>; Wed, 2 Oct 1996 20:09:43 -0500 (CDT)
Received: from tomswift2 (usr8ip16.azstarnet.com [169.197.9.16]) by mailhost.azstarnet.com (8.7.6/8.7.6) with SMTP id SAA00804 for <hfsig@tapr.org>; Wed, 2 Oct 1996 18:08:39 -0700 (MST)
Date: Wed, 2 Oct 1996 18:08:39 -0700 (MST)
Message-Id: <1.5.4.32.19961002180827.0036ddd0@azstarnet.com>
X-Sender: lylej@azstarnet.com
X-Mailer: Windows Eudora Light Version 1.5.4 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
To: hfsig@tapr.org
From: Lyle Johnson <lylej@azstarnet.com>
Subject: Re: [HFSIG:1554] RE: Development Environment

Danny,

ARD has no graphical front end. You type a textual netlist into it.

Cheers,

Lyle

***

At 03:19 PM 10/2/96 -0500, you wrote:
>On  den 2 oktober 1996 14:42, Bloom, Jon,  KE3Z[SMTP:jbloom@arrl.org]=
 wrote:
>
>> Whenever I've thought about this in
>> the past it was always the graphical front-end that made me shy away
>> from pursuing it, but I think Lyle has a good idea of a way around that.
>
>Is the ARRL Radio designer not a viable solution to this or is it not
>advanced enough?
>
>H=E4lsningar / Regards
>Danny Kohn - SM0NBJ
>Utvecklingskonsult / Development Consultant
>Systematik Consuliting AB - www.systematik.se - +46 708 140 300
>
>
>

From wd5ivd@tapr.org Thu Oct 03 10:01:29 1996
Received: (from wd5ivd@localhost) by tapr.org (8.7.5/8.7.3/1.9) id KAA15057; Thu, 3 Oct 1996 10:01:19 -0500 (CDT)
From: Greg Jones <wd5ivd@tapr.org>
Message-Id: <199610031501.KAA15057@tapr.org>
Subject: TAPR Office to reduce to minimum operations
To: tapr-bb@tapr.org (TAPR-BB mailing), tapr-board@tapr.org (TAPR Board),
        netsig@tapr.org (NETSIG mailing), bbssig@tapr.org (BBS SIG mailing),
        hfsig@tapr.org (HF SIG mailing), dsp-93@tapr.org (DSP-93 Build),
        aprssig@tapr.org (BBS SIG mailing), tapr-sys@tapr.org,
        amsat-bb@amsat.org (AMSAT BB Mail Group)
Date: Thu, 3 Oct 1996 10:01:18 -0500 (CDT)
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

TAPR Office to reduce to minimum operations                     Oct 3, 1996
-------------------------------------------

The TAPR Office will shutdown to minimum operations starting October 8th and
running at least until October 28th.

This means that Dorothy will not be working the office phones during this
period.  The office will continue to operate, but at a much reduced level.
E-mail, US mail, Voice Mail, etc will still be received and recorded, but
everything will be processed at a very much slower rate during this period.

GPS-20 units have begun to ship.  As of this e-mail, approximately 40 units
have shipped.  We are awaiting additional pins for the connector (suppose to
arrive Oct 11th) in order to complete the remainder of the units.  These
pins replace the ones that were incorrect in the shipment we received.  Once
the pins arrive, we will get the other units out as soon as possible.

The Motorola EVM56002 have been placed on order and are expected to arrive
sometime after Oct 21st.  They will then be shipped out as time permits
under the operational schedule at the office.  There are something like 60 of
the 200 units still available in this purchase at the $85 + $10 s/h price.
Check the TAPR Web page for full details www.tapr.org.  First come basis on
these units.

TAPR is sorry for any delays that the reduced operations schedule at the
office might cause.  If everything turns out positive, the office should be
back operational towards the end of October.  



Cheers - Greg Jones, WD5IVD
President, TAPR

(wd5ivd@tapr.org)

From forrerj@peak.org  Thu Oct 03 14:12:59 1996
Received: from PEAK.ORG (root@PEAK.ORG [198.68.22.17]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id OAA25399 for <hfsig@tapr.org>; Thu, 3 Oct 1996 14:12:57 -0500 (CDT)
Received: from p09.t0.monrotel.com (p06.t0.monrotel.com [198.68.25.39]) by PEAK.ORG (8.6.13/8.6.7) with SMTP id MAA26419 for <hfsig@tapr.org>; Thu, 3 Oct 1996 12:13:05 -0700
Message-Id: <199610031913.MAA26419@PEAK.ORG>
X-Sender: forrerj@peak.org
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 03 Oct 1996 12:10:04 -0800
To: hfsig@tapr.org
From: forrerj@peak.org (Johan Forrer)
Subject: Re: [HFSIG:1551] Development Environment

Hi Lyle,

Nice to see you on HFSIG.

There have been several attempts in doing this kind of thing: The Berkely
Ptolemy project, products from Hyperception, White Mountain and others.
There are also a few toy programs on the web that is interesting. 

I cannot make claims or offer any advice on how good they are as I have not
seriously tried any of these myself.

>I'm wondering if anyone on this sig has the knowledge and inclination to do
>something like this?  Perhaps those that are good DSP coders could write the
>various "modules" and someone strong in compiler knowledge could write the
>tool that took the "netlist" and created the source module to run through
>the mfr's assembler/linker/etc.
>
>I could be persuaded to work on schematic symbols and so forth for at least
>one or two popular (inexpensive?) windows-based tools (like the one from
>Ivex, for example).
>
>Does this sort of idea appeal to anyone else?  IF so, which DSP chip(s)?  I
>tend to lean towards the ADSP-2181, but then TAPR is sponsoring the DSP56002
>development board buy, so that may make more sense to target...

I was just wondering; how much of the SPROC effort is still usable and
available for a bootstrap effort? Can we use the Orcad front-end for
example? Perhaps if the format of it's output could be interpreted/compiled
or translated using compiler generator tools such as LEX, or YACC or similar
tools. 

Providing the appropiate DSP modules to run the code on a DSP platform may
perhaps need a bit of planning. This kind of modular engineering is perfect
for object-oriented programming design. Code may not quite be as efficient,
but perhaps good enough for serious experimentation on a contemporary DSP.
One of the student papers at the DCC did quite a nice job of showing how
these concepts worked - their case was a satellite ground station
controller, but might just as well have been a communications model.

Not that I'm volunteering either, but perhaps may be interested in a
professional effort. Heck, I was wondering when I was ever going to justify
the time I spent in graduate school learing about FA, FSM's and compiler theory.

My 2 cents worth.

--Johan


From forrerj@peak.org  Thu Oct 03 14:13:02 1996
Received: from PEAK.ORG (root@PEAK.ORG [198.68.22.17]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id OAA25417 for <hfsig@tapr.org>; Thu, 3 Oct 1996 14:13:00 -0500 (CDT)
Received: from p09.t0.monrotel.com (p06.t0.monrotel.com [198.68.25.39]) by PEAK.ORG (8.6.13/8.6.7) with SMTP id MAA26423 for <hfsig@tapr.org>; Thu, 3 Oct 1996 12:13:09 -0700
Message-Id: <199610031913.MAA26423@PEAK.ORG>
X-Sender: forrerj@peak.org
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 03 Oct 1996 12:10:08 -0800
To: hfsig@tapr.org
From: forrerj@peak.org (Johan Forrer)
Subject: Eb/No calculations

Hi Theoreticians,

I have been playing the numbers game a bit to grasp the significance of
Eb/No rather
than power ratios. Tom, N5EG have been kind to help review some of the
examples shown here, but if its wrong blame me :-)

It would be greatly appreciated if you could look over these calculations
and straighten me out if you spot something amiss. 

Comments/critisism or suggestions are welcome - post here for the benifit of
others.

Thanks in advance,

--Johan 


-----------------------------CUT
HERE--------------------------------------------

------------------------NB-(GAUSSIAN CHANNELS ASSUMED)-NB---------------------
                               Example 1:
------------------------------------------------------------------------------
Say we have an AMTOR signal (100 bits/sec, binary FSK), and given that 
AMTOR throughput goes down to zero at roughly -2.5 dB S/N (4000 Hz 
bandwidth), what is the equivalent Eb/N0 ?

           By definition; "Signal-to-Noise" power ratio = 10log(P/N) 
           Thus; P/N=antilog(-2.5/10)=0.5623

 A few useful relations:
           1) N=N0*B  where N0=noise density in watts/Hz
	   2) P=Eb*Rs where Rs=log2(M)/T (M=no of alphabet symbols)
                                         (T=symbol time)
       thus   P=100*Eb
                   
 Then,     Eb/(N0*4000)=0.5623 or 
           Eb/N0=(4000/100)*0.5623=22.492
                =10*log(22.492) dB
                =13.52 dB

------------------------------------------------------------------------------
                               Example 2:
------------------------------------------------------------------------------
There are claims that the new Pactor 2 protocol can work to a S/N level
of -18 dB. Pactor 2 in its most robust mode uses two parallel BPSK 
carriers, each coded at 100 symbols/sec, which effectively yields 
200 bits/sec. What is the equivalent Eb/N0? Would you agree that the 
claims have some credibility given the Shannon limit of -1.6 dB Eb/N0?

            Noise power = N0*3000, 
 Thus	             P/N=0.015848

 First consider a single carrier; 
	      P=Eb*Rs where Rs=log2(M)/T (M=total no of symbols)
                                         (T=symbol time)
                              =1/(1/100)
              P=100*Eb  (normalized, per bit)

 The total power for the two carriers is 2*P, however the energy per bit 
 is only half that because there are effectively two bits per symbol.

 Thus          Eb/N0=(3000/(100))*0.015848= -3.22 dB < -1.6 dB !!

The claims seems marginal, but try a S/N of -16 dB that 
equals -1.22 dB Eb/N0, which is probably as far down
as you can go, in theory at least. The claims are thus within 
ball-park numbers, at least, that is how I would interpret it.

Changing the protocol to redundantly replicate bits in the two channels, yields
only half the bit rate, but adds robustness, for then Eb/No at -16 dB S/N
translates 1.78 dB Eb/N0.

Now for comparitive purposes: QUATOR uses four parallel channels at 
75 symbols/sec. In the most robust mode, bits are redundantly replicated
over the 
four channels. Given this, then; -16 dB S/N corresponds to 6.0 dB Eb/N0. 
At this level there should still be throughput (given that the ECC
is doing it's bit) - in fact, it appears that the theoretical limit is 
approached around -23 dB S/N, which equals -0.96 dB Eb/N0.

------------------------------------------------------------------------------
                               Example 3:
------------------------------------------------------------------------------
QUATOR's modulation scheme uses a symbol rate of 75 baud
and packs 16 bits/symbol under good conditions. Say the system has a 
measured BER of 10E^-5 at 11 dB S/N in a 3000 Hz bandwidth. What is 
the equivalent Eb/N0?

 Similarly; Noise power = N0*3000, 
 Thus	             P/N=12.5893
 
	      P=Eb*Rs where Rs=log2(M)/T (M=no of signals)
                                          (T=symbol time)
                              =16/(1/75)
              P=16*75*Eb  (normalized, per bit)

 or      Eb/N0=(3000/(16*75))*12.59893=31.4973=14.98 dB	


For a few other (much higher error rates, not specified):

               2 dB  (3000 Hz BW) equates to    5.98 dB Eb/N0
-----------------------------------------------------------------------------
              -2 dB             "               1.98 dB	Eb/N0
(See Example 1, this is the approximate S/N level where AMTOR stops working.
QUATOR, however, seems to be some working margin, it may even be possible to
work
at one of its higher throughput levels - given ECC coding does it's bit.)
----------------------------------------------------------------------------- 
              -5 dB             "              -1.02 dB	Eb/N0
-----------------------------------------------------------------------------



From karn@qualcomm.com Thu Oct 03 17:21:17 1996
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id RAA02339 for <hfsig@tapr.org>; Thu, 3 Oct 1996 17:21:15 -0500 (CDT)
Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id PAA14157; Thu, 3 Oct 1996 15:20:44 -0700 (PDT)
Date: Thu, 3 Oct 1996 15:20:44 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199610032220.PAA14157@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <199610031913.MAA26423@PEAK.ORG> (forrerj@peak.org)
Subject: Re: [HFSIG:1558] Eb/No calculations

Johan,

Eb/N0 depends *user data rate*, not symbol rate or signal bandwidth.
Some of your examples appear to use modulation symbol rate in their
calculations, which is incorrect. And you don't mention what coding,
if any, is in use by the three schemes. You can easily get numbers
that appear to beat the Shannon Limit if you look at coded symbol rate
rather than user data rate.

Eb/N0 is derived as follows:

	Eb = S/R
	N0 = N/B
	Eb/N0 = (S/R) / (N/B) = (S/N) * (B/R)

where 

S = total rx signal power, watts
N = total rx noise power, watts
B = bandwidth in which N is measured, Hz
R = user data rate, bits/sec (*not* code or modulation symbol rate)

Here's one way to measure Eb/N0.

1. Measure the average signal power. If the modem is a hybrid ARQ type
that relies on code combining (e.g., Pactor), average the power over
some number of transmit-receive cycles. If you want, you can do this
by measuring the TX-on power and multiplying by the transmit duty
cycle.

2. Measure the average user data throughput. Since the data probably
comes out in fast bursts separated by pauses (particularly if the
modem uses FEC and/or ARQ), you can measure the average throughput
across some number of T-R cycles.

3. Divide the average signal power by the average throughput. This
gives the average signal energy per bit, Eb.

4. Measure the noise spectral energy, No. This can be done by
measuring the average received noise power in some known measurement
bandwidth and then dividing by that bandwidth. If you use a spectrum
analyzer, be sure to use a lot of video filtering to flatten out the
"grass" so you measure the true average noise power and not the
momentary fluctuating peak of some narrowband component.

5. Divide Eb by N0.

--Phil

From N0AOT@aol.com Fri Oct 04 01:20:43 1996
Received: from emout01.mail.aol.com (emout01.mx.aol.com [198.81.11.92]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id BAA24824 for <hfsig@tapr.org>; Fri, 4 Oct 1996 01:20:42 -0500 (CDT)
From: N0AOT@aol.com
Received: by emout01.mail.aol.com (8.6.12/8.6.12) id CAA01164; Fri, 4 Oct 1996 02:19:38 -0400
Date: Fri, 4 Oct 1996 02:19:38 -0400
Message-ID: <961004021937_324734913@emout01.mail.aol.com>
To: hfsig@tapr.org, forrerj@peak.org
Subject: Re: [HFSIG:1527] Re: Johan's modem

Hi Johan--

What about our beloved DSP56002EVM ??? ;>)

--Bob


In a message dated 96-09-10 21:21:52 EDT, you write:

>>As far as the actual implementation, at least what I am doing; I have been
>>using the PSA sound card platform thus far. This seems to have worked out
>>exteremely well for coding various parts of the modem, i.e., for monitoring
>>the workings of things like Costas loops and bit sync algorithms. 
>>For the future, however, I'm not sure which way I'll go. My experience with
>>the new TI 320C31 DSK has been very encouraging - perhaps too little
memory,
>>but it is really nice for the task, the speed and dynamic range, and a high
>>speed connection with the PC. This would make an ideal free-standing
>>implementation. On the other hand, I'm tempted to develop on the PC using
>>the soundblaster, but that would have no chance of ever getting the the ARQ
>>mode to work. I will, however, be able to play with the broadcast and CSMA
>>modes. 


From forrerj@peak.org  Fri Oct 04 11:01:23 1996
Received: from PEAK.ORG (root@PEAK.ORG [198.68.22.17]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id LAA08843 for <hfsig@tapr.org>; Fri, 4 Oct 1996 11:01:21 -0500 (CDT)
Received: from p08.t0.monrotel.com (p08.t0.monrotel.com [198.68.25.41]) by PEAK.ORG (8.6.13/8.6.7) with SMTP id JAA05817 for <hfsig@tapr.org>; Fri, 4 Oct 1996 09:01:31 -0700
Message-Id: <199610041601.JAA05817@PEAK.ORG>
X-Sender: forrerj@peak.org
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 04 Oct 1996 08:58:33 -0800
To: hfsig@tapr.org
From: forrerj@peak.org (Johan Forrer)
Subject: Re: [HFSIG:1560] Re: Johan's modem

Hi Bob,

How are you? Long time.

>Hi Johan--
>
>What about our beloved DSP56002EVM ??? ;>)
>
>--Bob

Don't give up too soon, hopefully I will get to that in the not too distant
future. 

The only reason why not the EVM presently, is the lack of a high speed link
between the EVM and the host computer. Experimental work required a detailed
study of various parts of the demodulator such as loop filters and tracking
algorithms working at the sample rate. It is thus not unusual to collect the
internal states over a few bit periods and end up with a huge file on the
host. The soundcard does this elegantly with no sweat. Once things are
working, however, the amount of data will probably be at a much lower rate,
i.e., at symbol rates instead of sample rates, also contain only the bare
necessities. At this time data would probably be able to be sent over a
serial interface. There also still remains a possibility to implement a high
speed parallel interface to the EVM for this purpose - you are bound to hear
more about this in future.

Have you had the opportunity to do some fun things with your EVM?

73's

--Johan

From lay@cod.nosc.mil Fri Oct 04 12:47:02 1996
Received: from trout.nosc.mil (trout.nosc.mil [128.49.16.7]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id MAA12757 for <hfsig@tapr.org>; Fri, 4 Oct 1996 12:47:00 -0500 (CDT)
Received: from marlin.nosc.mil by trout.nosc.mil (4.1/SMI-4.1)
	id AA29350; Fri, 4 Oct 96 10:46:53 PDT
Received: from sam.nosc.mil by marlin.nosc.mil (4.1/SMI-4.1)
	id AA28255; Fri, 4 Oct 96 10:46:52 PDT
Date: Fri, 4 Oct 96 10:46:52 PDT
Message-Id: <9610041746.AA28255@marlin.nosc.mil>
X-Sender: lay@cod.nosc.mil
X-Mailer: Windows Eudora Pro Version 2.1.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: hfsig@tapr.org
From: Richard Lay <lay@cod.nosc.mil>
Subject: Error Detecting Codes

I'm interested in detecting errors in a block of bits.  I don't really care
about correcting them, or even how many errors there are.  What options are
there?

I've heard of an error detection scheme where you send data blocks encoded
so that there are an equal number of ones and zeros.  If the number of ones
and zeros is not equal on reception, then there is an error.  This seems to
detect all odd number of error cases, but only about half the even number of
error cases.  I need to do better than that.

Regards,

Richard Lay

From forrerj@peak.org  Fri Oct 04 17:31:12 1996
Received: from PEAK.ORG (root@PEAK.ORG [198.68.22.17]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id RAA22134 for <hfsig@tapr.org>; Fri, 4 Oct 1996 17:31:08 -0500 (CDT)
Received: from p08.t0.monrotel.com (p04.t0.monrotel.com [198.68.25.37]) by PEAK.ORG (8.6.13/8.6.7) with SMTP id PAA20798 for <hfsig@tapr.org>; Fri, 4 Oct 1996 15:31:08 -0700
Message-Id: <199610042231.PAA20798@PEAK.ORG>
X-Sender: forrerj@peak.org
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 04 Oct 1996 15:28:20 -0800
To: hfsig@tapr.org
From: forrerj@peak.org (Johan Forrer)
Subject: Impressions of the 1996 DCC

Hi,

I promised that I would give my impressions of the last ARRL Digital
Communications Conference (DCC) held in Seattle September 20-22, 1996. There
was a short bit that I posted earlier - this is a continuation.



        Like most of us, there was only opportunity to attend a few of the
activities as much of it was parallel sessions. Also, I did not attend any
of the workshops, which was about APRS and high speed networking. My
apologies that I probably won't do justice to the work and effort that went
into doing these workshops. I heard it was great.
        There was the usual series of introductory talks: Digital
Communications, HF Digital Communications, and this time; an Introduction to
Spread Spectrum (SS). Greg Jones was a very energetic speaker and did a
great job on the introductory stuff. Steve Bible gave a thought-provoking
introduction to the topic of SS. What was interesting to me was hearing how
such a new mode of operation would be like; some form of channelized tuning
or scanning operation probably with a very strange-sounding background -
like tuning the band but now it was all SS codes. It was evident that SS was
on everyone's mind. The room was absolutely packed while the talk next door
was only a partially filled up - eventhough that also was a good one.
        There were two papers by students participating in the "Best
Student's Paper" - that went over well. The quality of their work was
excellent. One presentation dealt with the control system for an amateur
radio satellite ground station. Talk about sophistication; this one uses the
QNX real time operating system (it is small and compact enough that it lives
entirely in a Pentuim's L cache) as a basis and designed the various control
modules using the object-oriented programming concept called "Actor(s)". I
hope that the idea of the Student Awards would continue to produce and
attract such talented participants.
        Phil Karn presented some of his recent work on concatenated codes.
These are combined convolutional and block codes that has some rather neat
properties. This talk was outstanding as Phil really is the master of this
topic and the content was appreciated by many - judged by the full house.
There was an interesting comment on the future of research on coding theory.
Phil was talking here about "Turbo codes" and noted that once that have been
formalized, the last bit of coding gain would have been accounted for. So if
you were a coding theory theoretician, you would better find another field
to work in! However, I suspect there remains a great deal of this facinating
theory to be explored in HF digital applications.
        Interest in the future development of HF digital was shown in Craig
McCartney's (WA8DRZ) talk, which was about a commerial marine radio
operation - how HF digital communications and the Internet makes this possible. 
        The dinner speaker was Lyle Johnson - one of the founding fathers of
TAPR. Lyle reminded us that the role and place of Amateur Radio in today's
society was never as much in peril as now. Just think of the fact that we
are still using 1200 baud packet; that SSB is still the main voice
modulation method of choice. How long ago were these technolgies developed?
Why have we not made progress? It comes to no surprize that the amateur
committment to provide emergency readyness is being challenged by the coming
of age of the Internet, robust fiber optic communications, LEO's etc. I hope
the gloomy picture will inspire future experimentation and development of
our spectrum resources or realize that there are eager eyes wanting to claim it.
        The HFSIG meeting was held after dinner and provided intellectual
entertainment for those interested in HF. I think this was successful - at
least from where I was standing on the other side of the podium! The topic
this time was woven around past discussions we have had on HFSIG regarding
HF Channel simulation. 
Tom McDermott gave an excellent presentation of the mechnics involved in
simulation using the Watterson model, that I followed with showing a number
of "doppler grams", courtesy of Peter Martinez, G3PLX. These are really
unique and worth seeing. A brief overview of software for the DSP-93 and a
demo running this implementation of the Watterson ionospheric model,
concluded this part of the meeting. I also presented an
outline of the work that I have been doing on QUATOR.
        I wanted to talk about the future of HFSIG and made a desperate plea
for someone to offer to help out. My personal business committments has
gotten extremely demanding to the point where I just felt it necessary to
step back and let someone else continue with the good work that started, and
still continues, on this SIG. Being in the chair position means being at a
focal point with a lot happening behind the scenes. One need to process,
culture, follow up, and be involved constantly as there are a numerous
exiting and worthy opportunities coming your way. 

So keep that in mind: Anyone interested to help run HFSIG please get in
touch with Greg or me. Otherwise as of the DCC, I will remain an interested
party, but probably stay on the sidelines and participate whenever there is
an opportunity.

        I trust that this summary is of interest - remember that these are
my personal views and observations; one person's view of the world - I hope
I have most of the facts staight but short memory often let's me down. Thank
you much to all that made attending the conference a worthwhile experiece.
It was great seeing all and looking forward to the next DCC (which I hear
will be out on the East Coast).

73's and take care.

--Johan, KC7WW


From srbible@gnatnet.net Fri Oct 04 17:36:20 1996
Received: from rupe.gnatnet.net (root@rupe.gnatnet.net [206.30.198.8]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id RAA22353; Fri, 4 Oct 1996 17:36:18 -0500 (CDT)
Received: from avatar.eagnet.com (dialup14.gnatnet.net [206.30.198.114]) by rupe.gnatnet.net (8.6.13/8.6.12) with SMTP id SAA09491; Fri, 4 Oct 1996 18:36:52 -0400
Message-Id: <1.5.4.32.19961004223618.006b07f0@gnatnet.net>
X-Sender: srbible@gnatnet.net
X-Mailer: Windows Eudora Light Version 1.5.4 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 04 Oct 1996 18:36:18 -0400
To: tapr-bb@tapr.org, hfsig@tapr.org, amsat-bb@amsat.org
From: "Steven R. Bible" <srbible@gnatnet.net>
Subject: ARRL & TAPR DCC in the Linux Gazette

Phil Hughes, WA6SWR, publisher of the Linux Journal visited the ARRL & TAPR
DCC conference in Seattle on September 20-22.  I think Phil was pleasently
surprised to find that Linux was being used by hams.  He's written a short
piece in the Linux Gazette, an online magazine about Linux, about the DCC.
The article is titled:

    Hams, Packet Radio and Linux

and it's located at:

    http://www.ssc.com/lg/issue10/radio.html

I also have noted that a future issue of the Linux Journal is going to have
a piece about satellite tracking.  For more info see:

    http://www.ssc.com/

Disclaimer: No I have NOTHING to do with SCC.  I'm just a fanatical user of
Linux since version 0.96!

73,

 - Steve, N7HPR
 (n7hpr@tapr.org)

From Dave_Moore@ATK.COM Fri Oct 04 18:04:38 1996
Received: from ATK.COM (nic.ATK.COM [138.64.4.2]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id SAA23141 for <hfsig@tapr.org>; Fri, 4 Oct 1996 18:04:36 -0500 (CDT)
Received: from Exchange_MN1.ATK.COM by ATK.COM 
	id SAA16221; Fri, 4 Oct 1996 18:04:04 -0500
Received: by Exchange_MN1.ATK.COM with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5)
	id <01BBB21E.7389E300@Exchange_MN1.ATK.COM>; Fri, 4 Oct 1996 18:04:14 -0500
Message-ID: <c=US%a=_%p=ATK%l=EXCHANGE_MN1-961004230412Z-29007@Exchange_MN1.ATK.COM>
From: Dave Moore <Dave_Moore@ATK.COM>
To: "hfsig@tapr.org" <hfsig@tapr.org>
Subject: Out of Office AutoReply: [HFSIG:1560] HFSIG digest 166
Date: Fri, 4 Oct 1996 18:04:12 -0500
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5
Encoding: 3 TEXT

Out until Monday 10/7, but will check VoiceMail and check mail in the
evenings. May be reached at 921-8844 for more urgent messages.
Thanks, Dave Moore 

From wd5ivd@tapr.org Sat Oct 05 02:54:03 1996
Received: (from wd5ivd@localhost) by tapr.org (8.7.5/8.7.3/1.9) id CAA14873; Sat, 5 Oct 1996 02:53:55 -0500 (CDT)
From: Greg Jones <wd5ivd@tapr.org>
Message-Id: <199610050753.CAA14873@tapr.org>
Subject: EVM56002 Group Purchase Update
To: tapr-bb@tapr.org (TAPR-BB mailing),
        amsat-bb@amsat.org (AMSAT BB Mail Group), dsp-93@tapr.org,
        hfsig@tapr.org (HF SIG mailing)
Date: Sat, 5 Oct 1996 02:53:54 -0500 (CDT)
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

TAPR EVM56002 Group Purchase Update

The last sixty TAPR EVM56002 group purchase units have been spoken for.
Purchase is closed.

Cheers - Greg, WD5IVD

From alanb@polecat.sr.hp.com Sat Oct 05 21:32:15 1996
Received: from relay.hp.com (relay.hp.com [15.255.152.2]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id VAA13493 for <hfsig@tapr.org>; Sat, 5 Oct 1996 21:32:13 -0500 (CDT)
Received: from srmail.sr.hp.com by relay.hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA150429048; Sat, 5 Oct 1996 19:30:49 -0700
Received: from polecat.sr.hp.com (algae.sr.hp.com) by srmail.sr.hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA204789042; Sat, 5 Oct 1996 19:30:43 -0700
Received: by polecat.sr.hp.com
	(1.37.109.16/15.5+ECS 3.3) id AA008609042; Sat, 5 Oct 1996 19:30:42 -0700
From: Alan Bloom <alanb@polecat.sr.hp.com>
Message-Id: <199610060230.AA008609042@polecat.sr.hp.com>
Subject: ARRL DCC
To: hfsig@tapr.org
Date: Sat, 5 Oct 1996 19:30:41 -0800 (PDT)
X-Mailer: ELM [version 2.4 PL21]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

forrerj@peak.org (Johan Forrer) wrote:

>I promised that I would give my impressions of the last ARRL Digital
>Communications Conference (DCC) held in Seattle September 20-22, 1996. 

An excellent summary for those of us who couldn't go.  I wish I had time 
to attend more of these gatherings.  Too bad it wasn't the next weekend 
so I could have combined it with a business trip to Spokane that Monday.

>    The dinner speaker was Lyle Johnson - one of the founding fathers of
>TAPR. Lyle reminded us that the role and place of Amateur Radio in today's
>society was never as much in peril as now. Just think of the fact that we
>are still using 1200 baud packet; that SSB is still the main voice
>modulation method of choice. How long ago were these technolgies developed?
>Why have we not made progress? 

It's interesting to note that SSB is a very spectrum-efficient mode, 
even by today's standards.  You can pack about 10 SSB signals (more 
using spectrum-folding techniques) in the space of one analog cellular 
channel, which is better than most of the digital modes in use today.  
Don't get me wrong -- there are lots of good reasons to go digital.  
(Cost, size, reliability, easier integration of modems and other new 
features.)  But the oft-heard statement that "digital modes are much 
more spectrum-efficient than analog" is only true if you compare modern 
digital technology with the 50-year-old wideband FM currently used 
on the US cellular bands.

Alan Bloom N1AL

From lylej@azstarnet.com Sat Oct 05 23:50:44 1996
Received: from mailhost.azstarnet.com (mailhost.azstarnet.com [169.197.1.8]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id XAA19324 for <hfsig@tapr.org>; Sat, 5 Oct 1996 23:50:39 -0500 (CDT)
Received: from tomswift2 (usr1ip61.azstarnet.com [169.197.2.61]) by mailhost.azstarnet.com (8.7.6/8.7.6) with SMTP id VAA13546 for <hfsig@tapr.org>; Sat, 5 Oct 1996 21:49:28 -0700 (MST)
Date: Sat, 5 Oct 1996 21:49:28 -0700 (MST)
Message-Id: <1.5.4.32.19961005214925.003584a8@azstarnet.com>
X-Sender: lylej@azstarnet.com
X-Mailer: Windows Eudora Light Version 1.5.4 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: hfsig@tapr.org
From: Lyle Johnson <lylej@azstarnet.com>
Subject: Re: [HFSIG:1567] ARRL DCC

Alan,

Actually, as I understand things, for a given amount of power and Hz, you
can send more (voice) information using SS techniques than you could using SSB.

I remember making long distance phone calls a decade or two ago, and you
often heard the FDM SSB chatter on adjacent channels on the overseas
circuit.  Now, telephone systems are digital, and I would have to guess that
if the satellite transponders (a definite power limited situation) could
squeeze more voice cirvuits in using an FDM SSB system than they can over
the same path using digital techniques, they would.

SOm eof the more astute spread spectrum guys can probably give us alot of
informaitonm on how a given system can actually handle more voices using
these technqieus than can be done using SSB.

I think the problem is that spread spectrum techniques are "non intuitive" -
you just somehow *know* deep inside that narrowband is how you slice things
finer :-)

Having said that, I ahve certainly enjoyed using SSB over the years, and it
is lots better than many other methods!

Cheers,

Lyle

>It's interesting to note that SSB is a very spectrum-efficient mode, 
>even by today's standards.  You can pack about 10 SSB signals (more 
>using spectrum-folding techniques) in the space of one analog cellular 
>channel, which is better than most of the digital modes in use today.  
>Don't get me wrong -- there are lots of good reasons to go digital.  
>(Cost, size, reliability, easier integration of modems and other new 
>features.)  But the oft-heard statement that "digital modes are much 
>more spectrum-efficient than analog" is only true if you compare modern 
>digital technology with the 50-year-old wideband FM currently used 
>on the US cellular bands.

From lylej@azstarnet.com Sun Oct 06 00:05:23 1996
Received: from mailhost.azstarnet.com (mailhost.azstarnet.com [169.197.1.8]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id AAA23268 for <hfsig@tapr.org>; Sun, 6 Oct 1996 00:05:20 -0500 (CDT)
Received: from tomswift2 (usr1ip61.azstarnet.com [169.197.2.61]) by mailhost.azstarnet.com (8.7.6/8.7.6) with SMTP id WAA14778 for <hfsig@tapr.org>; Sat, 5 Oct 1996 22:04:09 -0700 (MST)
Date: Sat, 5 Oct 1996 22:04:09 -0700 (MST)
Message-Id: <1.5.4.32.19961005220406.0036a760@azstarnet.com>
X-Sender: lylej@azstarnet.com
X-Mailer: Windows Eudora Light Version 1.5.4 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: hfsig@tapr.org
From: Lyle Johnson <lylej@azstarnet.com>
Subject: Re: [HFSIG:1557] Re: Development Environment

Johann,

>There have been several attempts in doing this kind of thing: The Berkely
>Ptolemy project, products from Hyperception, White Mountain and others.
>There are also a few toy programs on the web that is interesting. 

The project I was proposing was to create an environment that could be used
on a standalone DSP to operate as a real-time system.  I know that some of
these you mention work with a plug-in card (usually big buck$).

For example, at work we evaluated a communications system from "IQ Comm" in
New York.  This is an $8,000 software package that lets you model
communications channels, etc. (we sent it back).  The problem is that they
have nice little building blocks that implmemnt "perfect" QPSK demodulators,
for example, but give no clue as to how to implmement such a demodualtor,
much less implmenment it for a given processor in real time.

The SPROC system, on the other hand, didn't model anything.  Essentially,
they had pre-compiled a large number of functional blocks (AGC, sine
generators of specified accuracy, "VCOs," ampliers, mixers (real and
complex)) and so forth.  The schematic capture system was used as a
graphical front end to tie these blocks together and embed the needed
parameters to properly operate (e.g., sampling rate, gain, attach and decay
rates, and so forth).  They also kindly included source code for all
functions and it was heavily commnted (and copyrighted).  Now that they are
and have been defunct for quite some time, maybe the copyright isn't a big
deal?  They had a 24-bit processor that used a 2.22 number format, so it was
a little odd, but the Motorola EVM could probably handle it easily enough.

>...
>I was just wondering; how much of the SPROC effort is still usable and
>available for a bootstrap effort? Can we use the Orcad front-end for
>example? Perhaps if the format of it's output could be interpreted/compiled
>or translated using compiler generator tools such as LEX, or YACC or similar
>tools. 

Orcad can generate a number of netlist formats.  Hoever, Ivex has a windows
based schematic package that also support various netlist formats (I
beleive) and is really cheap - free download with 100 "pins" (signals in our
case - ought to be plenty) and for $29.95 they increase that to 250 "pins."
For a few hundred $ they have unlimited size, but for this application we
can get by with either the free of the $30 version, I suspect.  Check out
"http://www.ivex.com" right there in Oregon - excellent package IMHO. 

>Providing the appropiate DSP modules to run the code on a DSP platform may
>perhaps need a bit of planning. This kind of modular engineering is perfect
>for object-oriented programming design. Code may not quite be as efficient,
>but perhaps good enough for serious experimentation on a contemporary DSP.
>One of the student papers at the DCC did quite a nice job of showing how
>these concepts worked - their case was a satellite ground station
>controller, but might just as well have been a communications model.

I think you are correct here.  We'd need to identify the modules we want to
start with (enough to make some interesting implmenetations; not too many to
discourage the effort from ever taking off) and then apportion some tasks.
Once we got it running for one DSP, it might not be that hard to make it
work for others... ?

>Not that I'm volunteering either, but perhaps may be interested in a
>professional effort. Heck, I was wondering when I was ever going to justify
>the time I spent in graduate school learing about FA, FSM's and compiler
theory.

No one is volunteering :-( but that doesn't mean we can't do it anyway :-)

I think the debug environment is key to making this worthwhile.  SPROC
really was an outstanding chip in this regard, since you could look at
anyting in real time and alter memory locations on the fly.  SOme of the DSP
chips with JTAG or JTAG-like serial pprts allow similar things (I'm thinking
particularly of the TMS320C31 and the newer Motorola devices - maybe the DMA
interface on the ADSP-2181 woudl also allow on-the-fly inspection and
modification).

Food for thought.

Cheers,

Lyle

From cn1743@coastalnet.com Sun Oct 06 12:56:52 1996
Received: from lucky.coastalnet.com (abaco.coastalnet.com [204.183.40.2]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id MAA14156 for <hfsig@tapr.org>; Sun, 6 Oct 1996 12:56:50 -0500 (CDT)
Received: from louis-dupree (pm-knst2-61.coastalnet.com [204.183.47.61]) by lucky.coastalnet.com (8.6.12/8.6.12) with SMTP id NAA02066 for <hfsig@tapr.org>; Sun, 6 Oct 1996 13:55:58 -0400
Message-Id: <2.2.32.19961006175642.006c0aa4@abaco.coastalnet.com>
X-Sender: cn1743@abaco.coastalnet.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 06 Oct 1996 13:56:42 -0400
To: hfsig@tapr.org
From: Louis Dupree <cn1743@coastalnet.com>
Subject: Unsubscribe

How do I unsubscribe from this group? I have tried and says I am not on the
list. I am getting emil for this group. I enjoy it, but I am going to be
away for several weeks, and I do not want to miss my personal email and my
ISP willonly store so much. Thank you. 73's Louis
Louis J. Dupree Jr.
3015 Englewood Dr.
Kinston, NC 28504
ldupree@coastalnet.com

From forrerj@peak.org  Sun Oct 06 13:34:23 1996
Received: from PEAK.ORG (root@PEAK.ORG [198.68.22.17]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id NAA15316 for <hfsig@tapr.org>; Sun, 6 Oct 1996 13:34:21 -0500 (CDT)
Received: from p00.t0.monrotel.com (p00.t0.monrotel.com [198.68.25.33]) by PEAK.ORG (8.6.13/8.6.7) with SMTP id LAA04836 for <hfsig@tapr.org>; Sun, 6 Oct 1996 11:34:27 -0700
Message-Id: <199610061834.LAA04836@PEAK.ORG>
X-Sender: forrerj@peak.org
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 06 Oct 1996 11:31:46 -0800
To: hfsig@tapr.org
From: forrerj@peak.org (Johan Forrer)
Subject: Re: [HFSIG:1569] Re: Development Environment

Hi Lyle,

> The problem is that they
>have nice little building blocks that implmemnt "perfect" QPSK demodulators,
>for example, but give no clue as to how to implmement such a demodualtor,
>much less implmenment it for a given processor in real time.

I suspect that some of these are attempts to generalize the world and thus
end up being as big and unwieldy as they are. Perhaps a more specific
solution is what is needed.

>
>The SPROC system, on the other hand, didn't model anything.  Essentially,
>they had pre-compiled a large number of functional blocks (AGC, sine
>generators of specified accuracy, "VCOs," ampliers, mixers (real and
>complex)) and so forth.  The schematic capture system was used as a
>graphical front end to tie these blocks together and embed the needed
>parameters to properly operate (e.g., sampling rate, gain, attach and decay
>rates, and so forth).  

........ 

> Hoever, Ivex has a windows
>based schematic package that also support various netlist formats (I
>beleive) and is really cheap - free download with 100 "pins" (signals in our
>case - ought to be plenty) and for $29.95 they increase that to 250 "pins."
>For a few hundred $ they have unlimited size, but for this application we
>can get by with either the free of the $30 version, I suspect.  Check out
>"http://www.ivex.com" right there in Oregon - excellent package IMHO. 
>

I'll have a look at this. 

Without getting into copyright issues, would it be possible to compile a
list of the basic functional blocks, a brief functional description, and a
list of their respective inputs and outputs? (I'll be willing to do this if
the materials can be made available.)

Presently we use software with the 56002 EVM that is based on the "Leonid"
kernel. Using these kernel services, relieves the code developer from a
number of tricky tasks such as dealing with low-level code for the CODEC's
real time data streams, serial communications etc. These services are
implemented by using assembly-language macro calls. It would certainly be
possible to build and extend a library of macros to include these functional
blocks as described above. 

Conceiveably then, an assembly language programmer can then put a working
commmunications model together simply by including the appropiate macros.
Having this macro library available then, it would perhaps be a little
easier to build a bridge between the model description language.     

How does this sound? 

--Johan

From chbrain@dircon.co.uk Sun Oct 06 14:32:30 1996
Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id OAA17325 for <hfsig@tapr.org>; Sun, 6 Oct 1996 14:32:28 -0500 (CDT)
Received: by felix.dircon.co.uk id AA20700
  (5.67b/IDA-1.5 for <hfsig@tapr.org>); Sun, 6 Oct 1996 20:26:18 +0100
Received: from gw2-166.pool.dircon.co.uk(194.112.35.166) by amnesiac via smap (V1.3)
	id sma020675; Sun Oct  6 20:26:03 1996
Message-Id: <1.5.4.32.19961006182332.0066333c@popmail.dircon.co.uk>
X-Sender: chbrain@popmail.dircon.co.uk
X-Mailer: Windows Eudora Light Version 1.5.4 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 06 Oct 1996 19:23:32 +0100
To: hfsig@tapr.org
From: Charles Brain <chbrain@dircon.co.uk>
Subject: Turbo Codes

Does anybody know of any good links to information on Turbo Codes.

Thanks 

Charles (G4GUO)

From alanb@polecat.sr.hp.com Sun Oct 06 14:52:30 1996
Received: from hp.com (hp.com [15.255.152.4]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id OAA18061 for <hfsig@tapr.org>; Sun, 6 Oct 1996 14:52:28 -0500 (CDT)
Received: from srmail.sr.hp.com by hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA269891545; Sun, 6 Oct 1996 12:52:25 -0700
Received: from polecat.sr.hp.com (algae.sr.hp.com) by srmail.sr.hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA177971544; Sun, 6 Oct 1996 12:52:24 -0700
Received: by polecat.sr.hp.com
	(1.37.109.16/15.5+ECS 3.3) id AA008811543; Sun, 6 Oct 1996 12:52:23 -0700
From: Alan Bloom <alanb@polecat.sr.hp.com>
Message-Id: <199610061952.AA008811543@polecat.sr.hp.com>
Subject: ARRL DCC
To: hfsig@tapr.org
Date: Sun, 6 Oct 1996 12:52:23 -0800 (PDT)
X-Mailer: ELM [version 2.4 PL21]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Lyle Johnson <lylej@azstarnet.com> wrote:

>Actually, as I understand things, for a given amount of power and Hz, you
>can send more (voice) information using SS techniques than you could using SSB.

Of course, the answer you get depends on the assumptions you make, but 
in general that is not true.  Compared with other digital modes, the 
"coding gain" you get with spread spectrum is cancelled out by the extra 
noise from the greater bandwidth.  And an SSB signal is actually more 
efficient than uncoded digital modulation.  For example, if the sampling 
frequency is 10 kHz, with 10 bits per sample, the data rate would be 
100 kbps, or over 100 kHz bandwidth for GMSK.  The SSB signal's 3 kHz 
bandwidth has an inherent 15 dB advantage in signal/noise ratio.

For a digital system to get power/bandwidth efficiency similar to SSB, 
it must use speech coding to get the data rate down.  More complex
modulation modes reduce the bandwidth at the expense of RF S/N ratio 
required.  And channel coding improves the received S/N ratio, assuming 
a minimum RF signal level.  Of course, there are also things you can do 
with SSB signals to improve the bandwidth and S/N, like spectrum folding 
and speech companding.  I suspect that SSB is still very competitive for 
applications where a low received S/N ratio is acceptable, like amateur
HF DX'ing, but that state-of-the-art digital modes are superior for 
applications where you need telephone-quality audio, like cellular radio.

>Now, telephone systems are digital, and I would have to guess that
>if the satellite transponders (a definite power limited situation) could
>squeeze more voice cirvuits in using an FDM SSB system than they can over
>the same path using digital techniques, they would.

Not necessarily.  Customers demand high-quality audio, where digital 
modes have an advantage.  Also all-digital systems are cheaper, easier 
to maintain and more convenient for sending digital data.  

As I said before, there are good reasons for going digital, but "digital 
modulation is more spectrum efficient than analog" is not one of them.  

Alan Bloom N1AL

From cn1743@coastalnet.com Sun Oct 06 16:43:32 1996
Received: from lucky.coastalnet.com (abaco.coastalnet.com [204.183.40.2]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id QAA22219 for <hfsig@tapr.org>; Sun, 6 Oct 1996 16:43:30 -0500 (CDT)
Received: from louis-dupree (pm-knst2-50.coastalnet.com [204.183.47.50]) by lucky.coastalnet.com (8.6.12/8.6.12) with SMTP id RAA13913 for <hfsig@tapr.org>; Sun, 6 Oct 1996 17:42:39 -0400
Message-Id: <2.2.32.19961006214325.00678168@abaco.coastalnet.com>
X-Sender: cn1743@abaco.coastalnet.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 06 Oct 1996 17:43:25 -0400
To: hfsig@tapr.org
From: Louis Dupree <cn1743@coastalnet.com> (by way of Louis Dupree <cn1743@coastalnet.com>)
Subject: [HFSIG:1570] Unsubscribe

How do I unsubscribe from this group? I have tried and says I am not on the
list. I am getting emil for this group. I enjoy it, but I am going to be
away for several weeks, and I do not want to miss my personal email and my
ISP willonly store so much. Thank you. 73's Louis
Louis J. Dupree Jr.
3015 Englewood Dr.
Kinston, NC 28504
ldupree@coastalnet.com



From lylej@azstarnet.com Sun Oct 06 20:07:05 1996
Received: from mailhost.azstarnet.com (mailhost.azstarnet.com [169.197.1.8]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id UAA29354 for <hfsig@tapr.org>; Sun, 6 Oct 1996 20:07:03 -0500 (CDT)
Received: from tomswift2 (usr7ip11.azstarnet.com [169.197.8.11]) by mailhost.azstarnet.com (8.7.6/8.7.6) with SMTP id SAA17247 for <hfsig@tapr.org>; Sun, 6 Oct 1996 18:05:52 -0700 (MST)
Date: Sun, 6 Oct 1996 18:05:52 -0700 (MST)
Message-Id: <1.5.4.32.19961006180550.00372be8@azstarnet.com>
X-Sender: lylej@azstarnet.com
X-Mailer: Windows Eudora Light Version 1.5.4 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: hfsig@tapr.org
From: Lyle Johnson <lylej@azstarnet.com>
Subject: Re: [HFSIG:1571] Re: Development Environment

Johan,

It sounds good to me.  It'll provide a great test of the concept, I think.

I'll dig up my old SPROC literature and list out the modules they included
(it was a big list, so be patient...)

Cheers,

Lyle

***
>Without getting into copyright issues, would it be possible to compile a
>list of the basic functional blocks, a brief functional description, and a
>list of their respective inputs and outputs? (I'll be willing to do this if
>the materials can be made available.)
>
>Presently we use software with the 56002 EVM that is based on the "Leonid"
>kernel. Using these kernel services, relieves the code developer from a
>number of tricky tasks such as dealing with low-level code for the CODEC's
>real time data streams, serial communications etc. These services are
>implemented by using assembly-language macro calls. It would certainly be
>possible to build and extend a library of macros to include these functional
>blocks as described above. 
>
>Conceiveably then, an assembly language programmer can then put a working
>commmunications model together simply by including the appropiate macros.
>Having this macro library available then, it would perhaps be a little
>easier to build a bridge between the model description language.     
>
>How does this sound? 

From forrerj@peak.org  Sun Oct 06 23:14:33 1996
Received: from PEAK.ORG (root@PEAK.ORG [198.68.22.17]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id XAA06218 for <hfsig@tapr.org>; Sun, 6 Oct 1996 23:14:30 -0500 (CDT)
Received: from p06.t0.monrotel.com (p06.t0.monrotel.com [198.68.25.39]) by PEAK.ORG (8.6.13/8.6.7) with SMTP id VAA26234 for <hfsig@tapr.org>; Sun, 6 Oct 1996 21:14:40 -0700
Message-Id: <199610070414.VAA26234@PEAK.ORG>
X-Sender: forrerj@peak.org
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 06 Oct 1996 21:12:15 -0800
To: hfsig@tapr.org
From: forrerj@peak.org (Johan Forrer)
Subject: Re: [HFSIG:1570] Unsubscribe



>How do I unsubscribe from this group? I have tried and says I am not on the
>list. I am getting emil for this group. I enjoy it, but I am going to be
>away for several weeks, and I do not want to miss my personal email and my
>ISP willonly store so much. Thank you. 73's Louis
>Louis J. Dupree Jr.
>3015 Englewood Dr.
>Kinston, NC 28504
>ldupree@coastalnet.com
>
>

An e-mail message to listserv@tapr.org with  UNSUBSCRIBE HFSIG in the body
will do it. Otherwise, use your web browser and it will guide you to
unsubscribe from any SIG.

Hope it helps.

Johan

From rs@ife.ee.ethz.ch Mon Oct 07 00:59:06 1996
Received: from ife.ee.ethz.ch (ife-ife0.ee.ethz.ch [129.132.25.1]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id AAA15951 for <hfsig@tapr.org>; Mon, 7 Oct 1996 00:59:03 -0500 (CDT)
Received: from gillespie.ee.ethz.ch (rs@gillespie.ee.ethz.ch [129.132.25.135]) by ife.ee.ethz.ch (8.8.0/8.8.0) with SMTP id HAA11317 for <hfsig@tapr.org>; Mon, 7 Oct 1996 07:58:57 +0200 (MET DST)
From: Rolf Sommerhalder <rs@ife.ee.ethz.ch>
Received: by gillespie.ee.ethz.ch (8.6.11) id HAA08461; Mon, 7 Oct 1996 07:58:57 +0200
Message-Id: <199610070558.HAA08461@gillespie.ee.ethz.ch>
Subject: Re: [HFSIG:1572] Turbo Codes
To: hfsig@tapr.org
Date: Mon, 7 Oct 1996 07:58:57 +0200 (MET DST)
In-Reply-To: <1.5.4.32.19961006182332.0066333c@popmail.dircon.co.uk> from Charles Brain at "Oct 6, 96 02:41:18 pm"
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

> Does anybody know of any good links to information on Turbo Codes.
> Charles (G4GUO)

Try
http://class1.ee.virginia.edu/CSL/turbo_codes/
and
http://charli.Levels.UniSA.Edu.Au:80/~steven/turbo/

73,
Rolf, HB9CWP

From karn@qualcomm.com Mon Oct 07 03:50:31 1996
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id DAA19918 for <hfsig@tapr.org>; Mon, 7 Oct 1996 03:50:28 -0500 (CDT)
Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id BAA21733; Mon, 7 Oct 1996 01:49:54 -0700 (PDT)
Date: Mon, 7 Oct 1996 01:49:54 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199610070849.BAA21733@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <9610041746.AA28255@marlin.nosc.mil> (message from Richard Lay on Fri, 4 Oct 1996 13:01:11 -0500 (CDT))
Subject: Re: [HFSIG:1562] Error Detecting Codes

>I'm interested in detecting errors in a block of bits.  I don't really care
>about correcting them, or even how many errors there are.  What options are
>there?

Any block code can detect errors with relatively little overhead. It's
only if you want to *correct* a lot of them that you start needing a
lot of overhead. Have you considered a simple CRC?

>I've heard of an error detection scheme where you send data blocks encoded
>so that there are an equal number of ones and zeros.  If the number of ones
>and zeros is not equal on reception, then there is an error.  This seems to
>detect all odd number of error cases, but only about half the even number of
>error cases.  I need to do better than that.

That's not a very strong code for error detection purposes; in coding
speak, the "minimum distance" is only 2, which is very small (ie, it
is easily fooled by errors).  This kind of code is much more useful as
a way to control the signal spectrum, as keeping the numbers of 0s and
1s equal tends to get rid of low frequency components. Again, just try
a CRC.

Phil

From karn@qualcomm.com Mon Oct 07 05:10:36 1996
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id FAA21687 for <hfsig@tapr.org>; Mon, 7 Oct 1996 05:10:34 -0500 (CDT)
Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id DAA21955; Mon, 7 Oct 1996 03:10:02 -0700 (PDT)
Date: Mon, 7 Oct 1996 03:10:02 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199610071010.DAA21955@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <199610060230.AA008609042@polecat.sr.hp.com> (message from Alan Bloom on Sat, 5 Oct 1996 21:42:38 -0500 (CDT))
Subject: Re: [HFSIG:1567] ARRL DCC

>It's interesting to note that SSB is a very spectrum-efficient mode, 
>even by today's standards.  You can pack about 10 SSB signals (more 
>using spectrum-folding techniques) in the space of one analog cellular 
>channel, which is better than most of the digital modes in use today.  
>Don't get me wrong -- there are lots of good reasons to go digital.  
>(Cost, size, reliability, easier integration of modems and other new 
>features.)  But the oft-heard statement that "digital modes are much 
>more spectrum-efficient than analog" is only true if you compare modern 
>digital technology with the 50-year-old wideband FM currently used 
>on the US cellular bands.

Warning: hot button alert!

The proper measure of spectrum efficiency in a cellular environment is
not QSOs per megahertz, but QSOs per megahertz PER SQUARE KILOMETER.

There's a very good reason (other than frequency stability and gain
control reasons) why AMPS (analog) cellular uses FM instead of
SSB. Thanks to its capture effect, FM can provide telephone quality
audio with about 10-11 dB SNIR (signal-to-noise-plus-interference), as
compared to about 25-30 dB for SSB.

Sure, SSB channels would have been narrower. But each channel would
have been usable in a *much* smaller fraction of the cells due to the
greater sensitivity to co-channel interference. This would more than
squander the "savings" due to the narrower channel.

Even FM AMPS generally uses each 30 KHz channel in only 1/7 of the
cells, which is a pretty stiff penalty. CDMA (spread spectrum) cellular
systems can use the same channel in *every* cell, making for a much
greater (10-15x) overall system capacity for the same cell sites and
spectral allocations.

Only now is it becoming generally understood that improving spectral
efficiency in an interference-limited environment means going *wider*,
not narrower. Unfortunately not even the FCC is immune to spurious
claims of spectral "efficiency" from narrowband systems -- we lost the
220-222 MHz band to one such claim.

Phil

From karn@qualcomm.com Mon Oct 07 05:18:26 1996
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id FAA21992 for <hfsig@tapr.org>; Mon, 7 Oct 1996 05:18:24 -0500 (CDT)
Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id DAA21965; Mon, 7 Oct 1996 03:17:52 -0700 (PDT)
Date: Mon, 7 Oct 1996 03:17:52 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199610071017.DAA21965@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <199610061834.LAA04836@PEAK.ORG> (forrerj@peak.org)
Subject: Re: [HFSIG:1571] Re: Development Environment

> The problem is that they
>have nice little building blocks that implmemnt "perfect" QPSK demodulators,
>for example, but give no clue as to how to implmement such a demodualtor,
>much less implmenment it for a given processor in real time.

Speaking from now considerable personal experience, I can say that
implementing a perfect QPSK demodulator in DSP is trivial. It's just a
pair of multiplies -- no big deal.

The real trick is in deriving the incoming carrier phase reference.
And doing this well is a real bitch (if not downright impossible) at
low data rates on channels with the slightest bit of unpredictable
movement (satellite or ionospheric motion, etc).

I now understand why QPSK is generally reserved for high speed channels
like DSS downlinks at 40 megabits/sec.

Phil

From karn@qualcomm.com Mon Oct 07 05:34:21 1996
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id FAA22329 for <hfsig@tapr.org>; Mon, 7 Oct 1996 05:34:19 -0500 (CDT)
Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id DAA22002; Mon, 7 Oct 1996 03:33:47 -0700 (PDT)
Date: Mon, 7 Oct 1996 03:33:47 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199610071033.DAA22002@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <199610061952.AA008811543@polecat.sr.hp.com> (message from Alan Bloom on Sun, 6 Oct 1996 15:02:43 -0500 (CDT))
Subject: Re: [HFSIG:1573] ARRL DCC

>Of course, the answer you get depends on the assumptions you make, but 
>in general that is not true.  Compared with other digital modes, the 

It *is* true if you consider IS-95 CDMA. See my web page for some
pointers to various papers.

http://www.qualcomm.com/people/pkarn/cdma.html

>in general that is not true.  Compared with other digital modes, the 
>"coding gain" you get with spread spectrum is cancelled out by the extra 
>noise from the greater bandwidth.  And an SSB signal is actually more 

Eh? It's true that spreading with direct sequence or frequency hopping
by itself does not change the Eb/N0 requirement, i.e., it's
"power-neutral". But if you make meaningful FEC part of the bandwidth
expansion, you come out well ahead. (Yes, you can think of FEC as a
form of spread spectrum -- after all, it *does* make the signal wider
than it otherwise would be if it were uncoded, right?)

>efficient than uncoded digital modulation.  For example, if the sampling 
>frequency is 10 kHz, with 10 bits per sample, the data rate would be 
>100 kbps, or over 100 kHz bandwidth for GMSK.  The SSB signal's 3 kHz 
>bandwidth has an inherent 15 dB advantage in signal/noise ratio.

A red herring. Nobody sends uncompressed digital voice over mobile radio.

>For a digital system to get power/bandwidth efficiency similar to SSB, 
>it must use speech coding to get the data rate down.  More complex
>modulation modes reduce the bandwidth at the expense of RF S/N ratio 
>required.  And channel coding improves the received S/N ratio, assuming 
>a minimum RF signal level.  Of course, there are also things you can do 

Yes, of course -- all digital cellular systems use speech coding.  But
by "more complex" modulation modes I assume you mean higher numbers of
bits per symbol, which is exactly the *wrong* thing to do for spectral
efficiency as that necessarily increases the Eb/N0 requirements.
Minimizing the required Eb/N0 is the key to an efficient digital radio
system, and that necessarily requires wider bandwidths.

>a minimum RF signal level.  Of course, there are also things you can do 
>with SSB signals to improve the bandwidth and S/N, like spectrum folding 
>and speech companding.  I suspect that SSB is still very competitive for 
>applications where a low received S/N ratio is acceptable, like amateur
>HF DX'ing, but that state-of-the-art digital modes are superior for 
>applications where you need telephone-quality audio, like cellular radio.

Information theory still applies, whether the signal is analog or
digital.  Anything you do to reduce bandwidth (without removing
information) is going to require extra power and make it harder to
reuse the channel on a geographical basis. That's unavoidable.

You're right that SSB works reasonably well at very low S/N ratios,
but I don't consider low SNRs acceptable even on ham radio. Who says
we shouldn't strive for decent audio quality, especially now that it's
within our reach? It's comparing apples and oranges to claim that SSB
"outperforms" digital modes when the quality setpoints are so
different.

Phil

From lylej@azstarnet.com Mon Oct 07 09:28:50 1996
Received: from mailhost.azstarnet.com (mailhost.azstarnet.com [169.197.1.8]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id JAA29210 for <hfsig@tapr.org>; Mon, 7 Oct 1996 09:28:48 -0500 (CDT)
Received: from tomswift2 (usr5ip52.azstarnet.com [169.197.6.52]) by mailhost.azstarnet.com (8.7.6/8.7.6) with SMTP id HAA22323 for <hfsig@tapr.org>; Mon, 7 Oct 1996 07:27:36 -0700 (MST)
Date: Mon, 7 Oct 1996 07:27:36 -0700 (MST)
Message-Id: <1.5.4.32.19961007072734.0036c944@pop.azstarnet.com>
X-Sender: lylej@pop.azstarnet.com
X-Mailer: Windows Eudora Light Version 1.5.4 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: hfsig@tapr.org
From: Lyle Johnson <lylej@azstarnet.com>
Subject: Re: [HFSIG:1580] Re: Development Environment

>The real trick is in deriving the incoming carrier phase reference.
>And doing this well is a real bitch (if not downright impossible) at
>low data rates on channels with the slightest bit of unpredictable
>movement (satellite or ionospheric motion, etc).

Yes, precisely.  THe "block" on the "simulator" just used the clock from the
transmit side and didn't bother to derive *any* clocks.  It was OK for
evaluating some things, but not nearly as useful as its price tag would have
indicated...

Cheers,

Lyle

From Ulf.Kumm@t-online.de  Mon Oct 07 11:03:25 1996
Received: from mailout00.btx.dtag.de (mailout00.btx.dtag.de [194.25.2.148]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id LAA03284 for <hfsig@tapr.org>; Mon, 7 Oct 1996 11:03:23 -0500 (CDT)
Received: from mailto00.btx.dtag.de ([172.16.2.1]) by mailout00.btx.dtag.de with
	 smtp (S3.1.29.1) id <m0vAHzs-000S1wC>; Mon, 7 Oct 96 17:53 MET DST
Received: from funnel27.btx.dtag.de (07117678924-0001(btxid)@[194.25.2.28]) 
	by mailto00.btx.dtag.de with  smtp (S3.1.29.1) 
	id <m0vAHzh-0008TtC>; Mon, 7 Oct 96 17:53 MET DST
Message-Id: <m0vAHzh-0008TtC@mailto00.btx.dtag.de>
Date: Mon, 7 Oct 96 17:53 MET DST
X-Mailer: Windows Eudora Light Version 1.5.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: hfsig@tapr.org
Subject: Async 4800Bd via FSK Tekk-Radio
X-Sender: 07117678924-0001@t-online.de (SYMEK Datensyst.u.Elektr.GmbH)
From: Ulf.Kumm@t-online.de (Ulf Kumm)

I have to transmit a asynchronous (RS232) signal (4800 Baud) via a radio link.
The link should be fully transparent and must not have the delay of a
packet-type link.
The TEKK-radio KS960 is capable to transmit/receive up to 9600Bd FSK,
AF-bandwidth is about 100 to 5000Hz. The link should transmit real time DGPS
data.

* Just connecting RS232 with the FSK-modulator-input does not work: the
floating decider
  needs some transitions to keep his trigger in the middle between 0 and 1,
but will
  loose sync while the RS232 signal pauses for some seconds.
* Any synchronous methods (manchester, hdlc or other bit-stuffing stuff) are
difficult
  because RS232 is asynchronous. But a 1 Byte delay is acceptable.
* I have to generate some edges on the FSK-signal to keep the RX-decider
working while
  the RS232 input pauses. 

The problem is easy to solve when the baudrate is just 1200 or 2400, I used
a simple
AFSK chip (TCM3105 or even XR2211/06). But these chips may not run with 4k8
(even if 
they do, the bandwidth would be >5kHz). The problem is, that my
FSK-transceivers are
AC-coupled and cannot be used with AF-frequencies below maybe 10 Hz, but
RS232 is a
really static DC-signal.

Does anybody have a simple solution to my problem ?
(I know, that there may exist a lot of complicated ones) 
Thanks for your hints!

Ulf Kumm, DK9SJ@DB0RBS.#BW.DEU.EU


----
Ulf Kumm, DK9SJ,   D-70597 Stuttgart, Johannes-Kraemer-Str. 34
eMail: Ulf.Kumm@t-online.de   Tel: +49 711 7678-925  Fax: -924  
----

From combdyn!uucp@uunet.ca  Mon Oct 07 11:30:51 1996
Received: from seraph.uunet.ca (uunet.ca [142.77.1.254]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id LAA04524 for <hfsig@tapr.org>; Mon, 7 Oct 1996 11:30:47 -0500 (CDT)
Received: from combdyn by seraph.uunet.ca with UUCP id <249698-14272>; Mon, 7 Oct 1996 12:30:34 -0400
Received: by combdyn (5.65/cdl1.26)
	id AA00083; Mon, 7 Oct 96 09:54:15 -0600
Date: Mon, 7 Oct 1996 11:54:15 -0400
From: combdyn!uucp@uunet.ca (UUCP Admin)
Posted-Date: Mon, 7 Oct 96 09:54:15 -0600
Message-Id: <9610071554.AA00083@combdyn>
Subject: Execution failed
To: tapr.org!hfsig@uunet.ca

Message from UUCP on combdyn Mon Oct  7 09:54:15 1996

Execution request failed:
	rmail combdyn.com!hfsig
Standard error output was:
rmail: Return to uunet.ca!tapr.org!hfsig

From combdyn!uucp@uunet.ca  Mon Oct 07 11:31:00 1996
Received: from seraph.uunet.ca (uunet.ca [142.77.1.254]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id LAA04576 for <hfsig@tapr.org>; Mon, 7 Oct 1996 11:30:54 -0500 (CDT)
Received: from combdyn by seraph.uunet.ca with UUCP id <249690-14275>; Mon, 7 Oct 1996 12:30:32 -0400
Received: by combdyn (5.65/cdl1.26)
	id AA00037; Mon, 7 Oct 96 09:54:11 -0600
Date: Mon, 7 Oct 1996 11:54:11 -0400
From: combdyn!uucp@uunet.ca (UUCP Admin)
Posted-Date: Mon, 7 Oct 96 09:54:11 -0600
Message-Id: <9610071554.AA00037@combdyn>
Subject: Execution failed
To: tapr.org!hfsig@uunet.ca

Message from UUCP on combdyn Mon Oct  7 09:54:10 1996

Execution request failed:
	rmail combdyn.com!hfsig
Standard error output was:
rmail: Return to uunet.ca!tapr.org!hfsig

From combdyn!uucp@uunet.ca  Mon Oct 07 11:31:12 1996
Received: from seraph.uunet.ca (uunet.ca [142.77.1.254]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id LAA04628 for <hfsig@tapr.org>; Mon, 7 Oct 1996 11:31:11 -0500 (CDT)
Received: from combdyn by seraph.uunet.ca with UUCP id <249698-14270>; Mon, 7 Oct 1996 12:30:53 -0400
Received: by combdyn (5.65/cdl1.26)
	id AA00451; Mon, 7 Oct 96 09:54:52 -0600
Date: Mon, 7 Oct 1996 11:54:52 -0400
From: combdyn!uucp@uunet.ca (UUCP Admin)
Posted-Date: Mon, 7 Oct 96 09:54:52 -0600
Message-Id: <9610071554.AA00451@combdyn>
Subject: Execution failed
To: tapr.org!hfsig@uunet.ca

Message from UUCP on combdyn Mon Oct  7 09:54:52 1996

Execution request failed:
	rmail combdyn.com!hfsig
Standard error output was:
rmail: Return to uunet.ca!tapr.org!hfsig

From combdyn!uucp@uunet.ca  Mon Oct 07 11:31:14 1996
Received: from seraph.uunet.ca (uunet.ca [142.77.1.254]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id LAA04631 for <hfsig@tapr.org>; Mon, 7 Oct 1996 11:31:12 -0500 (CDT)
Received: from combdyn by seraph.uunet.ca with UUCP id <249690-14269>; Mon, 7 Oct 1996 12:31:02 -0400
Received: by combdyn (5.65/cdl1.26)
	id AA00587; Mon, 7 Oct 96 09:55:09 -0600
Date: Mon, 7 Oct 1996 11:55:09 -0400
From: combdyn!uucp@uunet.ca (UUCP Admin)
Posted-Date: Mon, 7 Oct 96 09:55:09 -0600
Message-Id: <9610071555.AA00587@combdyn>
Subject: Execution failed
To: tapr.org!hfsig@uunet.ca

Message from UUCP on combdyn Mon Oct  7 09:55:09 1996

Execution request failed:
	rmail combdyn.com!hfsig
Standard error output was:
rmail: Return to uunet.ca!tapr.org!hfsig

From combdyn!uucp@uunet.ca  Mon Oct 07 11:31:16 1996
Received: from seraph.uunet.ca (uunet.ca [142.77.1.254]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id LAA04646 for <hfsig@tapr.org>; Mon, 7 Oct 1996 11:31:13 -0500 (CDT)
Received: from combdyn by seraph.uunet.ca with UUCP id <249661-14269>; Mon, 7 Oct 1996 12:30:54 -0400
Received: by combdyn (5.65/cdl1.26)
	id AA00513; Mon, 7 Oct 96 09:55:00 -0600
Date: Mon, 7 Oct 1996 11:55:00 -0400
From: combdyn!uucp@uunet.ca (UUCP Admin)
Posted-Date: Mon, 7 Oct 96 09:55:00 -0600
Message-Id: <9610071555.AA00513@combdyn>
Subject: Execution failed
To: tapr.org!hfsig@uunet.ca

Message from UUCP on combdyn Mon Oct  7 09:55:00 1996

Execution request failed:
	rmail combdyn.com!hfsig
Standard error output was:
rmail: Return to uunet.ca!tapr.org!hfsig

From combdyn!uucp@uunet.ca  Mon Oct 07 11:31:19 1996
Received: from seraph.uunet.ca (uunet.ca [142.77.1.254]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id LAA04682 for <hfsig@tapr.org>; Mon, 7 Oct 1996 11:31:17 -0500 (CDT)
Received: from combdyn by seraph.uunet.ca with UUCP id <249727-14275>; Mon, 7 Oct 1996 12:31:00 -0400
Received: by combdyn (5.65/cdl1.26)
	id AA00567; Mon, 7 Oct 96 09:55:07 -0600
Date: Mon, 7 Oct 1996 11:55:07 -0400
From: combdyn!uucp@uunet.ca (UUCP Admin)
Posted-Date: Mon, 7 Oct 96 09:55:07 -0600
Message-Id: <9610071555.AA00567@combdyn>
Subject: Execution failed
To: tapr.org!hfsig@uunet.ca

Message from UUCP on combdyn Mon Oct  7 09:55:07 1996

Execution request failed:
	rmail combdyn.com!hfsig
Standard error output was:
rmail: Return to uunet.ca!tapr.org!hfsig

From combdyn!uucp@uunet.ca  Mon Oct 07 11:31:21 1996
Received: from seraph.uunet.ca (uunet.ca [142.77.1.254]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id LAA04701 for <hfsig@tapr.org>; Mon, 7 Oct 1996 11:31:19 -0500 (CDT)
Received: from combdyn by seraph.uunet.ca with UUCP id <249640-14273>; Mon, 7 Oct 1996 12:30:46 -0400
Received: by combdyn (5.65/cdl1.26)
	id AA00204; Mon, 7 Oct 96 09:54:27 -0600
Date: Mon, 7 Oct 1996 11:54:27 -0400
From: combdyn!uucp@uunet.ca (UUCP Admin)
Posted-Date: Mon, 7 Oct 96 09:54:27 -0600
Message-Id: <9610071554.AA00204@combdyn>
Subject: Execution failed
To: tapr.org!hfsig@uunet.ca

Message from UUCP on combdyn Mon Oct  7 09:54:27 1996

Execution request failed:
	rmail combdyn.com!hfsig
Standard error output was:
rmail: Return to uunet.ca!tapr.org!hfsig

From combdyn!uucp@uunet.ca  Mon Oct 07 11:31:25 1996
Received: from seraph.uunet.ca (uunet.ca [142.77.1.254]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id LAA04733 for <hfsig@tapr.org>; Mon, 7 Oct 1996 11:31:23 -0500 (CDT)
Received: from combdyn by seraph.uunet.ca with UUCP id <249720-14271>; Mon, 7 Oct 1996 12:30:52 -0400
Received: by combdyn (5.65/cdl1.26)
	id AA00395; Mon, 7 Oct 96 09:54:46 -0600
Date: Mon, 7 Oct 1996 11:54:46 -0400
From: combdyn!uucp@uunet.ca (UUCP Admin)
Posted-Date: Mon, 7 Oct 96 09:54:46 -0600
Message-Id: <9610071554.AA00395@combdyn>
Subject: Execution failed
To: tapr.org!hfsig@uunet.ca

Message from UUCP on combdyn Mon Oct  7 09:54:46 1996

Execution request failed:
	rmail combdyn.com!hfsig
Standard error output was:
rmail: Return to uunet.ca!tapr.org!hfsig

From combdyn!uucp@uunet.ca  Mon Oct 07 11:31:31 1996
Received: from seraph.uunet.ca (uunet.ca [142.77.1.254]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id LAA04783 for <hfsig@tapr.org>; Mon, 7 Oct 1996 11:31:29 -0500 (CDT)
Received: from combdyn by seraph.uunet.ca with UUCP id <249680-14273>; Mon, 7 Oct 1996 12:30:49 -0400
Received: by combdyn (5.65/cdl1.26)
	id AA00290; Mon, 7 Oct 96 09:54:34 -0600
Date: Mon, 7 Oct 1996 11:54:34 -0400
From: combdyn!uucp@uunet.ca (UUCP Admin)
Posted-Date: Mon, 7 Oct 96 09:54:34 -0600
Message-Id: <9610071554.AA00290@combdyn>
Subject: Execution failed
To: tapr.org!hfsig@uunet.ca

Message from UUCP on combdyn Mon Oct  7 09:54:34 1996

Execution request failed:
	rmail combdyn.com!hfsig
Standard error output was:
rmail: Return to uunet.ca!tapr.org!hfsig

From combdyn!uucp@uunet.ca  Mon Oct 07 11:31:34 1996
Received: from seraph.uunet.ca (uunet.ca [142.77.1.254]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id LAA04815 for <hfsig@tapr.org>; Mon, 7 Oct 1996 11:31:32 -0500 (CDT)
Received: from combdyn by seraph.uunet.ca with UUCP id <249714-14274>; Mon, 7 Oct 1996 12:30:38 -0400
Received: by combdyn (5.65/cdl1.26)
	id AA00111; Mon, 7 Oct 96 09:54:18 -0600
Date: Mon, 7 Oct 1996 11:54:18 -0400
From: combdyn!uucp@uunet.ca (UUCP Admin)
Posted-Date: Mon, 7 Oct 96 09:54:18 -0600
Message-Id: <9610071554.AA00111@combdyn>
Subject: Execution failed
To: tapr.org!hfsig@uunet.ca

Message from UUCP on combdyn Mon Oct  7 09:54:18 1996

Execution request failed:
	rmail combdyn.com!hfsig
Standard error output was:
rmail: Return to uunet.ca!tapr.org!hfsig

From combdyn!uucp@uunet.ca  Mon Oct 07 11:31:39 1996
Received: from seraph.uunet.ca (uunet.ca [142.77.1.254]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id LAA04848 for <hfsig@tapr.org>; Mon, 7 Oct 1996 11:31:36 -0500 (CDT)
Received: from combdyn by seraph.uunet.ca with UUCP id <249717-14273>; Mon, 7 Oct 1996 12:30:43 -0400
Received: by combdyn (5.65/cdl1.26)
	id AA00134; Mon, 7 Oct 96 09:54:20 -0600
Date: Mon, 7 Oct 1996 11:54:20 -0400
From: combdyn!uucp@uunet.ca (UUCP Admin)
Posted-Date: Mon, 7 Oct 96 09:54:20 -0600
Message-Id: <9610071554.AA00134@combdyn>
Subject: Execution failed
To: tapr.org!hfsig@uunet.ca

Message from UUCP on combdyn Mon Oct  7 09:54:20 1996

Execution request failed:
	rmail combdyn.com!hfsig
Standard error output was:
rmail: Return to uunet.ca!tapr.org!hfsig

From combdyn!uucp@uunet.ca  Mon Oct 07 11:31:51 1996
Received: from seraph.uunet.ca (uunet.ca [142.77.1.254]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id LAA04918 for <hfsig@tapr.org>; Mon, 7 Oct 1996 11:31:48 -0500 (CDT)
Received: from combdyn by seraph.uunet.ca with UUCP id <249736-14271>; Mon, 7 Oct 1996 12:31:09 -0400
Received: by combdyn (5.65/cdl1.26)
	id AA00698; Mon, 7 Oct 96 09:55:24 -0600
Date: Mon, 7 Oct 1996 11:55:24 -0400
From: combdyn!uucp@uunet.ca (UUCP Admin)
Posted-Date: Mon, 7 Oct 96 09:55:24 -0600
Message-Id: <9610071555.AA00698@combdyn>
Subject: Execution failed
To: tapr.org!hfsig@uunet.ca

Message from UUCP on combdyn Mon Oct  7 09:55:24 1996

Execution request failed:
	rmail combdyn.com!hfsig
Standard error output was:
rmail: Return to uunet.ca!tapr.org!hfsig

From combdyn!uucp@uunet.ca  Mon Oct 07 11:31:56 1996
Received: from seraph.uunet.ca (uunet.ca [142.77.1.254]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id LAA04953 for <hfsig@tapr.org>; Mon, 7 Oct 1996 11:31:53 -0500 (CDT)
Received: from combdyn by seraph.uunet.ca with UUCP id <249707-14269>; Mon, 7 Oct 1996 12:31:04 -0400
Received: by combdyn (5.65/cdl1.26)
	id AA00607; Mon, 7 Oct 96 09:55:11 -0600
Date: Mon, 7 Oct 1996 11:55:11 -0400
From: combdyn!uucp@uunet.ca (UUCP Admin)
Posted-Date: Mon, 7 Oct 96 09:55:11 -0600
Message-Id: <9610071555.AA00607@combdyn>
Subject: Execution failed
To: tapr.org!hfsig@uunet.ca

Message from UUCP on combdyn Mon Oct  7 09:55:11 1996

Execution request failed:
	rmail combdyn.com!hfsig
Standard error output was:
rmail: Return to uunet.ca!tapr.org!hfsig

From RLANIER@mailb.harris.com  Mon Oct 07 11:57:38 1996
Received: from sol.corp.Harris.COM (sol.corp.harris.com [137.237.25.4]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id LAA06038 for <hfsig@tapr.org>; Mon, 7 Oct 1996 11:57:32 -0500 (CDT)
Received: from mailb.harris.com by sol.corp.Harris.COM (8.6.12/Kurts Special version 2.0)
	id MAA06383; Mon, 7 Oct 1996 12:57:21 -0400
Received: from ccMail by mailb.harris.com
  (IMA Internet Exchange 1.04b) id 25936160; Mon, 7 Oct 96 12:55:50 -0400
Mime-Version: 1.0
Date: Mon, 7 Oct 1996 12:56:39 -0400
Message-ID: <25936160@mailb.harris.com>
From: RLANIER@mailb.harris.com (RLANIER)
Subject: DSP filtering project
To: hfsig@tapr.org
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part

     I am currently working on a "simple" DSP filtering project for a 
     portable AM/FM radio. I am taking the guts from an old cassette-radio 
     I had and putting it into a new case along with a DSP chip (I'm using 
     the ADSP-2101). My idea is to filter out the noise generated by the 
     environment in an office (lights, computers, etc.) so I can listen to 
     talk radio  :) . The frequencies will be on the AM band; FM is not 
     affected. As you know, AM is greatly affected by noise. Building the 
     DSP radio is not a problem, its the filtering part that is in 
     question. Someone told me that filtering will not help in this 
     situation. Is this true?
     
     If you have any opinions, helpful hints or good advice, I would 
     appreciate hearing from you.
     
     73s de
     Tony,  KE4ATO

From wd5ivd@tapr.org Mon Oct 07 12:26:25 1996
Received: (from wd5ivd@localhost) by tapr.org (8.7.5/8.7.3/1.9) id MAA07588 for hfsig@tapr.org; Mon, 7 Oct 1996 12:26:24 -0500 (CDT)
From: Greg Jones <wd5ivd@tapr.org>
Message-Id: <199610071726.MAA07588@tapr.org>
Subject: Re: [HFSIG:1594] Execution failed
To: hfsig@tapr.org
Date: Mon, 7 Oct 1996 12:26:24 -0500 (CDT)
In-Reply-To: <9610071554.AA00134@combdyn> from "UUCP Admin" at Oct 7, 96 12:06:27 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

The group might get a few of these things -- but we have removed the account
in question.

Just press DELETE :-)

Greg


> 
> Message from UUCP on combdyn Mon Oct  7 09:54:20 1996
> 
> Execution request failed:
> 	rmail combdyn.com!hfsig
> Standard error output was:
> rmail: Return to uunet.ca!tapr.org!hfsig
> 
> 

From combdyn!uucp@uunet.ca  Mon Oct 07 12:42:53 1996
Received: from seraph.uunet.ca (uunet.ca [142.77.1.254]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id MAA08607 for <hfsig@tapr.org>; Mon, 7 Oct 1996 12:42:51 -0500 (CDT)
Received: from combdyn by seraph.uunet.ca with UUCP id <249635-24174>; Mon, 7 Oct 1996 13:42:40 -0400
Received: by combdyn (5.65/cdl1.26)
	id AA01401; Mon, 7 Oct 96 11:27:27 -0600
Date: Mon, 7 Oct 1996 13:27:27 -0400
From: combdyn!uucp@uunet.ca (UUCP Admin)
Posted-Date: Mon, 7 Oct 96 11:27:27 -0600
Message-Id: <9610071727.AA01401@combdyn>
Subject: Execution failed
To: tapr.org!hfsig@uunet.ca

Message from UUCP on combdyn Mon Oct  7 11:27:27 1996

Execution request failed:
	rmail combdyn.com!hfsig
Standard error output was:
rmail: Return to uunet.ca!tapr.org!hfsig

From tim@NMSU.Edu Mon Oct 07 13:33:34 1996
Received: from bubba.NMSU.Edu (bubba.NMSU.Edu [128.123.3.39]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id NAA13267 for <hfsig@tapr.org>; Mon, 7 Oct 1996 13:33:33 -0500 (CDT)
Received: from NMSU.Edu by bubba.NMSU.Edu (8.6.10/NMSU)
	id MAA26795; Mon, 7 Oct 1996 12:34:07 -0600
Received: from wilma by NMSU.Edu (8.6.10/NMSU-1.18)
	id MAA13264; Mon, 7 Oct 1996 12:33:29 -0600
Received: by wilma (4.1/NMSU)
	id AA08008; Mon, 7 Oct 96 12:33:29 MDT
Date: Mon, 7 Oct 1996 12:33:29 -0600 (MDT)
From: Tim Baggett <tim@NMSU.Edu>
X-Sender: tim@wilma
To: hfsig@tapr.org
Subject: UUCP Help
Message-Id: <Pine.SUN.3.91.961007122936.6652C-100000@wilma>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII



HELP!!! Will someone *PLEASE* make _it_ stop!

73
Tim, AA5DF

(Sorry, just a nervous twitch created by the incoming UUCP Errors as I'm 
trying to wade through a few hundred emails piled up while away) Reminds 
me of watching a BBS forward ;-)

From Glen_Worstell@notes.seagate.com Mon Oct 07 13:56:09 1996
Received: from ns1.seagate.com (ns1.seagate.com [204.160.183.10]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id NAA14384 for <hfsig@tapr.org>; Mon, 7 Oct 1996 13:56:05 -0500 (CDT)
Received: (from smap) by ns1.seagate.com (8.6.12/cf-v5) id LAA29036 for <hfsig@tapr.org>; Mon, 7 Oct 1996 11:53:22 -0700
Received: from unknown(134.204.114.75) by ns1 via smap (V1.3)
	id sma028999; Mon Oct  7 18:53:00 1996
Received: from notes.seagate.com (sv-mis4.stsv.seagate.com [134.204.14.86]) by ns.seagate.com (8.6.12/cf-v5) with SMTP id LAA21260 for <@ns.seagate.com:hfsig@tapr.org>; Mon, 7 Oct 1996 11:57:40 -0700
Received: by notes.seagate.com (IBM OS/2 SENDMAIL VERSION 1.3.17/1.0)
	  id AA7975; Mon, 07 Oct 96 12:01:11 -0700
Message-Id: <9610071901.AA7975@notes.seagate.com>
Received: by SEAGATE (Lotus Notes Mail Gateway for SMTP V1.1) id
  6EC0EB59AFA6C02D862563BC00683ACE; Mon,  7 Oct 96 12:01:10 
To: RLANIER <RLANIER@mailb.harris.com>
Cc: hfsig <hfsig@tapr.org>
From: Glen Worstell <Glen_Worstell@notes.seagate.com>
Date:  7 Oct 96 13:58:46 
Subject: Re: [HFSIG:1597] DSP filtering project
Mime-Version: 1.0
Content-Type: Text/Plain

>... My idea is to filter out the noise generated by the 
     environment in an office (lights, computers, etc.) so I can listen to 
     talk radio  :) ....Someone told me that filtering will not help in this 
     situation. Is this true?

Depends on the nature of the noise, but in general filtering can help
quite a bit.  Modern ham radio receivers have a noise blanker, and
with impulse noise of various sorts it can make a big difference.

Usually the signal needed to generate the noise-reduction comes
before the narrow band IF.

cheers,
glen.

From combdyn!uucp@uunet.ca  Mon Oct 07 14:29:18 1996
Received: from seraph.uunet.ca (uunet.ca [142.77.1.254]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id OAA15872 for <hfsig@tapr.org>; Mon, 7 Oct 1996 14:29:15 -0500 (CDT)
Received: from combdyn by seraph.uunet.ca with UUCP id <249635-10661>; Mon, 7 Oct 1996 15:29:11 -0400
Received: by combdyn (5.65/cdl1.26)
	id AA01512; Mon, 7 Oct 96 11:43:03 -0600
Date: Mon, 7 Oct 1996 13:43:03 -0400
From: combdyn!uucp@uunet.ca (UUCP Admin)
Posted-Date: Mon, 7 Oct 96 11:43:03 -0600
Message-Id: <9610071743.AA01512@combdyn>
Subject: Execution failed
To: tapr.org!hfsig@uunet.ca

Message from UUCP on combdyn Mon Oct  7 11:43:03 1996

Execution request failed:
	rmail combdyn.com!hfsig
Standard error output was:
rmail: Return to uunet.ca!tapr.org!hfsig

From combdyn!uucp@uunet.ca  Mon Oct 07 14:29:22 1996
Received: from seraph.uunet.ca (uunet.ca [142.77.1.254]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id OAA15905 for <hfsig@tapr.org>; Mon, 7 Oct 1996 14:29:20 -0500 (CDT)
Received: from combdyn by seraph.uunet.ca with UUCP id <249661-12588>; Mon, 7 Oct 1996 15:29:11 -0400
Received: by combdyn (5.65/cdl1.26)
	id AA01532; Mon, 7 Oct 96 11:43:06 -0600
Date: Mon, 7 Oct 1996 13:43:06 -0400

From: combdyn!uucp@uunet.ca (UUCP Admin)
Posted-Date: Mon, 7 Oct 96 11:43:06 -0600
Message-Id: <9610071743.AA01532@combdyn>
Subject: Execution failed
To: tapr.org!hfsig@uunet.ca

Message from UUCP on combdyn Mon Oct  7 11:43:05 1996

Execution request failed:
	rmail combdyn.com!hfsig
Standard error output was:
rmail: Return to uunet.ca!tapr.org!hfsig

From combdyn!uucp@uunet.ca  Mon Oct 07 14:29:40 1996
Received: from seraph.uunet.ca (uunet.ca [142.77.1.254]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id OAA15955 for <hfsig@tapr.org>; Mon, 7 Oct 1996 14:29:38 -0500 (CDT)
Received: from combdyn by seraph.uunet.ca with UUCP id <249722-11802>; Mon, 7 Oct 1996 15:29:16 -0400
Received: by combdyn (5.65/cdl1.26)
	id AA01592; Mon, 7 Oct 96 11:43:12 -0600
Date: Mon, 7 Oct 1996 13:43:12 -0400
From: combdyn!uucp@uunet.ca (UUCP Admin)
Posted-Date: Mon, 7 Oct 96 11:43:12 -0600
Message-Id: <9610071743.AA01592@combdyn>
Subject: Execution failed
To: tapr.org!hfsig@uunet.ca

Message from UUCP on combdyn Mon Oct  7 11:43:12 1996

Execution request failed:
	rmail combdyn.com!hfsig
Standard error output was:
rmail: Return to uunet.ca!tapr.org!hfsig

From combdyn!uucp@uunet.ca  Mon Oct 07 14:29:45 1996
Received: from seraph.uunet.ca (uunet.ca [142.77.1.254]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id OAA16004 for <hfsig@tapr.org>; Mon, 7 Oct 1996 14:29:44 -0500 (CDT)
Received: from combdyn by seraph.uunet.ca with UUCP id <249734-10283>; Mon, 7 Oct 1996 15:29:20 -0400
Received: by combdyn (5.65/cdl1.26)
	id AA01632; Mon, 7 Oct 96 11:43:16 -0600
Date: Mon, 7 Oct 1996 13:43:16 -0400
From: combdyn!uucp@uunet.ca (UUCP Admin)
Posted-Date: Mon, 7 Oct 96 11:43:16 -0600
Message-Id: <9610071743.AA01632@combdyn>
Subject: Execution failed
To: tapr.org!hfsig@uunet.ca

Message from UUCP on combdyn Mon Oct  7 11:43:16 1996

Execution request failed:
	rmail combdyn.com!hfsig
Standard error output was:
rmail: Return to uunet.ca!tapr.org!hfsig

From combdyn!uucp@uunet.ca  Mon Oct 07 14:29:49 1996
Received: from seraph.uunet.ca (uunet.ca [142.77.1.254]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id OAA16037 for <hfsig@tapr.org>; Mon, 7 Oct 1996 14:29:47 -0500 (CDT)
Received: from combdyn by seraph.uunet.ca with UUCP id <249737-10661>; Mon, 7 Oct 1996 15:29:23 -0400
Received: by combdyn (5.65/cdl1.26)
	id AA01652; Mon, 7 Oct 96 11:43:18 -0600
Date: Mon, 7 Oct 1996 13:43:18 -0400
From: combdyn!uucp@uunet.ca (UUCP Admin)
Posted-Date: Mon, 7 Oct 96 11:43:18 -0600
Message-Id: <9610071743.AA01652@combdyn>
Subject: Execution failed
To: tapr.org!hfsig@uunet.ca

Message from UUCP on combdyn Mon Oct  7 11:43:18 1996

Execution request failed:
	rmail combdyn.com!hfsig
Standard error output was:
rmail: Return to uunet.ca!tapr.org!hfsig

From combdyn!uucp@uunet.ca  Mon Oct 07 14:29:53 1996
Received: from seraph.uunet.ca (uunet.ca [142.77.1.254]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id OAA16057 for <hfsig@tapr.org>; Mon, 7 Oct 1996 14:29:49 -0500 (CDT)
Received: from combdyn by seraph.uunet.ca with UUCP id <249714-8990>; Mon, 7 Oct 1996 15:29:15 -0400
Received: by combdyn (5.65/cdl1.26)
	id AA01572; Mon, 7 Oct 96 11:43:10 -0600
Date: Mon, 7 Oct 1996 13:43:10 -0400
From: combdyn!uucp@uunet.ca (UUCP Admin)
Posted-Date: Mon, 7 Oct 96 11:43:10 -0600
Message-Id: <9610071743.AA01572@combdyn>
Subject: Execution failed
To: tapr.org!hfsig@uunet.ca

Message from UUCP on combdyn Mon Oct  7 11:43:10 1996

Execution request failed:
	rmail combdyn.com!hfsig
Standard error output was:
rmail: Return to uunet.ca!tapr.org!hfsig

From combdyn!uucp@uunet.ca  Mon Oct 07 14:30:00 1996
Received: from seraph.uunet.ca (uunet.ca [142.77.1.254]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id OAA16111 for <hfsig@tapr.org>; Mon, 7 Oct 1996 14:29:57 -0500 (CDT)
Received: from combdyn by seraph.uunet.ca with UUCP id <249680-10661>; Mon, 7 Oct 1996 15:29:13 -0400
Received: by combdyn (5.65/cdl1.26)
	id AA01552; Mon, 7 Oct 96 11:43:08 -0600
Date: Mon, 7 Oct 1996 13:43:08 -0400
From: combdyn!uucp@uunet.ca (UUCP Admin)
Posted-Date: Mon, 7 Oct 96 11:43:08 -0600
Message-Id: <9610071743.AA01552@combdyn>
Subject: Execution failed
To: tapr.org!hfsig@uunet.ca

Message from UUCP on combdyn Mon Oct  7 11:43:08 1996

Execution request failed:
	rmail combdyn.com!hfsig
Standard error output was:
rmail: Return to uunet.ca!tapr.org!hfsig

From combdyn!uucp@uunet.ca  Mon Oct 07 14:30:02 1996
Received: from seraph.uunet.ca (uunet.ca [142.77.1.254]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id OAA16130 for <hfsig@tapr.org>; Mon, 7 Oct 1996 14:30:00 -0500 (CDT)
Received: from combdyn by seraph.uunet.ca with UUCP id <249730-8990>; Mon, 7 Oct 1996 15:29:18 -0400
Received: by combdyn (5.65/cdl1.26)
	id AA01612; Mon, 7 Oct 96 11:43:14 -0600
Date: Mon, 7 Oct 1996 13:43:14 -0400
From: combdyn!uucp@uunet.ca (UUCP Admin)
Posted-Date: Mon, 7 Oct 96 11:43:14 -0600
Message-Id: <9610071743.AA01612@combdyn>
Subject: Execution failed
To: tapr.org!hfsig@uunet.ca

Message from UUCP on combdyn Mon Oct  7 11:43:14 1996

Execution request failed:
	rmail combdyn.com!hfsig
Standard error output was:
rmail: Return to uunet.ca!tapr.org!hfsig

From combdyn!uucp@uunet.ca  Mon Oct 07 14:42:57 1996
Received: from seraph.uunet.ca (uunet.ca [142.77.1.254]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id OAA16976 for <hfsig@tapr.org>; Mon, 7 Oct 1996 14:42:54 -0500 (CDT)
Received: from combdyn by seraph.uunet.ca with UUCP id <249696-11355>; Mon, 7 Oct 1996 15:42:48 -0400
Received: by combdyn (5.65/cdl1.26)
	id AA02216; Mon, 7 Oct 96 13:29:48 -0600
Date: Mon, 7 Oct 1996 15:29:48 -0400
From: combdyn!uucp@uunet.ca (UUCP Admin)
Posted-Date: Mon, 7 Oct 96 13:29:48 -0600
Message-Id: <9610071929.AA02216@combdyn>
Subject: Execution failed
To: tapr.org!hfsig@uunet.ca

Message from UUCP on combdyn Mon Oct  7 13:29:47 1996

Execution request failed:
	rmail combdyn.com!hfsig
Standard error output was:
rmail: Return to uunet.ca!tapr.org!hfsig

From combdyn!uucp@uunet.ca  Mon Oct 07 14:43:00 1996
Received: from seraph.uunet.ca (uunet.ca [142.77.1.254]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id OAA16994 for <hfsig@tapr.org>; Mon, 7 Oct 1996 14:42:56 -0500 (CDT)
Received: from combdyn by seraph.uunet.ca with UUCP id <249683-10661>; Mon, 7 Oct 1996 15:42:48 -0400
Received: by combdyn (5.65/cdl1.26)
	id AA02238; Mon, 7 Oct 96 13:29:51 -0600
Date: Mon, 7 Oct 1996 15:29:51 -0400
From: combdyn!uucp@uunet.ca (UUCP Admin)
Posted-Date: Mon, 7 Oct 96 13:29:51 -0600
Message-Id: <9610071929.AA02238@combdyn>
Subject: Execution failed
To: tapr.org!hfsig@uunet.ca

Message from UUCP on combdyn Mon Oct  7 13:29:51 1996

Execution request failed:
	rmail combdyn.com!hfsig
Standard error output was:
rmail: Return to uunet.ca!tapr.org!hfsig

From combdyn!uucp@uunet.ca  Mon Oct 07 14:43:14 1996
Received: from seraph.uunet.ca (uunet.ca [142.77.1.254]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id OAA17084 for <hfsig@tapr.org>; Mon, 7 Oct 1996 14:43:10 -0500 (CDT)
Received: from combdyn by seraph.uunet.ca with UUCP id <249715-8990>; Mon, 7 Oct 1996 15:42:50 -0400
Received: by combdyn (5.65/cdl1.26)
	id AA02258; Mon, 7 Oct 96 13:29:54 -0600
Date: Mon, 7 Oct 1996 15:29:54 -0400
From: combdyn!uucp@uunet.ca (UUCP Admin)
Posted-Date: Mon, 7 Oct 96 13:29:54 -0600
Message-Id: <9610071929.AA02258@combdyn>
Subject: Execution failed
To: tapr.org!hfsig@uunet.ca

Message from UUCP on combdyn Mon Oct  7 13:29:54 1996

Execution request failed:
	rmail combdyn.com!hfsig
Standard error output was:
rmail: Return to uunet.ca!tapr.org!hfsig

From combdyn!uucp@uunet.ca  Mon Oct 07 14:43:41 1996
Received: from seraph.uunet.ca (uunet.ca [142.77.1.254]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id OAA17128 for <hfsig@tapr.org>; Mon, 7 Oct 1996 14:43:39 -0500 (CDT)
Received: from combdyn by seraph.uunet.ca with UUCP id <249683-10283>; Mon, 7 Oct 1996 15:43:35 -0400
Received: by combdyn (5.65/cdl1.26)
	id AA02278; Mon, 7 Oct 96 13:29:58 -0600
Date: Mon, 7 Oct 1996 15:29:58 -0400
From: combdyn!uucp@uunet.ca (UUCP Admin)
Posted-Date: Mon, 7 Oct 96 13:29:58 -0600
Message-Id: <9610071929.AA02278@combdyn>
Subject: Execution failed
To: tapr.org!hfsig@uunet.ca

Message from UUCP on combdyn Mon Oct  7 13:29:57 1996

Execution request failed:
	rmail combdyn.com!hfsig
Standard error output was:
rmail: Return to uunet.ca!tapr.org!hfsig

From combdyn!uucp@uunet.ca  Mon Oct 07 14:43:55 1996
Received: from seraph.uunet.ca (uunet.ca [142.77.1.254]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id OAA17207 for <hfsig@tapr.org>; Mon, 7 Oct 1996 14:43:54 -0500 (CDT)
Received: from combdyn by seraph.uunet.ca with UUCP id <249715-10283>; Mon, 7 Oct 1996 15:43:36 -0400
Received: by combdyn (5.65/cdl1.26)
	id AA02314; Mon, 7 Oct 96 13:30:03 -0600
Date: Mon, 7 Oct 1996 15:30:03 -0400
From: combdyn!uucp@uunet.ca (UUCP Admin)
Posted-Date: Mon, 7 Oct 96 13:30:03 -0600
Message-Id: <9610071930.AA02314@combdyn>
Subject: Execution failed
To: tapr.org!hfsig@uunet.ca

Message from UUCP on combdyn Mon Oct  7 13:30:03 1996

Execution request failed:
	rmail combdyn.com!hfsig
Standard error output was:
rmail: Return to uunet.ca!tapr.org!hfsig

From MPFahmie@lbl.gov Mon Oct 07 16:02:42 1996
Received: from mh1.lbl.gov (mh1.lbl.gov [128.3.254.235]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id QAA20766 for <hfsig@tapr.org>; Mon, 7 Oct 1996 16:02:39 -0500 (CDT)
Received: from mikef (mikef.als.lbl.gov [128.3.129.114]) by mh1.lbl.gov (LBNLMWH3/G) with SMTP id OAA29719 for <hfsig@tapr.org>; Mon, 7 Oct 1996 14:02:38 -0700 (PDT)
Message-Id: <199610072102.OAA29719@mh1.lbl.gov>
X-Authentication-Warning: mh1.lbl.gov: Host mikef.als.lbl.gov [128.3.129.114] claimed to be mikef
X-Sender: mikef@mh1.lbl.gov
X-Mailer: Windows Eudora Pro Version 2.1.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 07 Oct 1996 13:59:05 -0700
To: hfsig@tapr.org
From: Mike Fahmie <MPFahmie@lbl.gov>
Subject: WWVB to QRO


According to an article in Wireless Systems Design (Sept,96), the NIST 60
KHz Time & Frequency station, WWVB will be increasing power.  The new
transmitter should be 'on line' by September of 1997 and will output over 40
KW, at least a 6 dB increase over the present system.  According to the
article, power is being increased so that smaller receive antennas may be used.

Anyone know if MSF is still running 50 KW from Rugby, England?  If so,
WWVB's QRO may cause some headaches for fringe MSF users.  I drove past the
Rugby site in 1989, biggest antenna farm I've ever seen!

-Mike-

                 Mike Fahmie   -   Advanced Light Source
                 Lawrence Berkeley National Laboratory
                 (510) 486-4030     -     MPFahmie@lbl.gov
                                   WA6ZTY @ N6EEG

From karn@qualcomm.com Mon Oct 07 17:45:50 1996
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id RAA27092 for <hfsig@tapr.org>; Mon, 7 Oct 1996 17:45:48 -0500 (CDT)
Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id PAA23433; Mon, 7 Oct 1996 15:45:16 -0700 (PDT)
Date: Mon, 7 Oct 1996 15:45:16 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199610072245.PAA23433@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <1.5.4.32.19961007072734.0036c944@pop.azstarnet.com> (message from Lyle Johnson on Mon, 7 Oct 1996 09:45:43 -0500 (CDT))
Subject: Re: [HFSIG:1582] Re: Development Environment

>Yes, precisely.  THe "block" on the "simulator" just used the clock from the
>transmit side and didn't bother to derive *any* clocks.  It was OK for

This is *cheating*! Anybody can do this and get great results. Doing it
on a real channel, with all its phase perturbations, is the real trick.

To the extent you can predict sources of phase variations and subtract
them out (e.g., by running a satellite tracking program to preduct
doppler) you can make things work better. But there are sources of
doppler that will surprise you.  For example, James Miller pointed out
to me that the S-band antenna on AO-13 is not mounted on the spin axis
of the spacecraft, so when the spacecraft is off pointed there is a
sinusoidal velocity component on the antenna as the spacecraft
rotates.  This can amount to 5 Hz. This is very significant with low
rate QPSK!

Even 3-axis-stabilized geostationary satellites are not immune. Though
there may be no doppler shift from the physical motion of the
satellite, there's still ionospheric scintillation.  This can be
surprisingly great even at microwave frequencies when the sun is
active.

Phil

From forrerj@peak.org  Mon Oct 07 18:54:41 1996
Received: from PEAK.ORG (root@PEAK.ORG [198.68.22.17]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id SAA29603 for <hfsig@tapr.org>; Mon, 7 Oct 1996 18:54:38 -0500 (CDT)
Received: from p07.t0.monrotel.com (p07.t0.monrotel.com [198.68.25.40]) by PEAK.ORG (8.6.13/8.6.7) with SMTP id QAA01568 for <hfsig@tapr.org>; Mon, 7 Oct 1996 16:54:47 -0700
Message-Id: <199610072354.QAA01568@PEAK.ORG>
X-Sender: forrerj@peak.org
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 07 Oct 1996 16:52:22 -0800
To: hfsig@tapr.org
From: forrerj@peak.org (Johan Forrer)
Subject: Re: [HFSIG:1577] Re: Turbo Codes

>> Does anybody know of any good links to information on Turbo Codes.
>> Charles (G4GUO)
>
>Try
>http://class1.ee.virginia.edu/CSL/turbo_codes/
>and
>http://charli.Levels.UniSA.Edu.Au:80/~steven/turbo/
>
>73,
>Rolf, HB9CWP
>
>

Thanks Rolf!

--Johan,KC7WW

From karn@qualcomm.com Mon Oct 07 20:29:21 1996
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id UAA03977 for <hfsig@tapr.org>; Mon, 7 Oct 1996 20:29:19 -0500 (CDT)
Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id SAA23784; Mon, 7 Oct 1996 18:28:48 -0700 (PDT)
Date: Mon, 7 Oct 1996 18:28:48 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199610080128.SAA23784@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <199610072102.OAA29719@mh1.lbl.gov> (message from Mike Fahmie on Mon, 7 Oct 1996 16:20:32 -0500 (CDT))
Subject: Re: [HFSIG:1615] WWVB to QRO

>According to an article in Wireless Systems Design (Sept,96), the NIST 60
>KHz Time & Frequency station, WWVB will be increasing power.  The new

Interesting. With the GPS revolution I would have thought that the
market for WWVB time & frequency receivers would be on the way
out. Not only are the GPS receivers cheaper, but it's a lot easier to
find roof space for their antennas.

Phil

From chbrain@dircon.co.uk Tue Oct 08 01:35:57 1996
Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id BAA22696 for <hfsig@tapr.org>; Tue, 8 Oct 1996 01:35:55 -0500 (CDT)
Received: by felix.dircon.co.uk id AA15168
  (5.67b/IDA-1.5 for <hfsig@tapr.org>); Tue, 8 Oct 1996 07:26:42 +0100
Received: from gw2-101.pool.dircon.co.uk(194.112.35.101) by amnesiac via smap (V1.3)
	id sma015133; Tue Oct  8 07:26:16 1996
Message-Id: <1.5.4.32.19961008052333.0067036c@popmail.dircon.co.uk>
X-Sender: chbrain@popmail.dircon.co.uk
X-Mailer: Windows Eudora Light Version 1.5.4 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 08 Oct 1996 06:23:33 +0100
To: hfsig@tapr.org
From: Charles Brain <chbrain@dircon.co.uk>
Subject: Re: [HFSIG:1615] WWVB to QRO

>Anyone know if MSF is still running 50 KW from Rugby, England?  If so,
>WWVB's QRO may cause some headaches for fringe MSF users.  I drove past the
>Rugby site in 1989, biggest antenna farm I've ever seen!
>
>-Mike-

Yes Rugby is still on air, there has been a lot of new Rugby controlled
clocks on sale
recently. I even saw a MSF Rugby gadget to connect to a LAN to synchronise
all the 
clocks on it. I have a Homebrew Rugby receiver but the QRM from the
computers here
makes it next to useless unless I turn them all off and of course one of
them decodes
the time signal! My receiver uses a ferrite rod (can't get much smaller than
that!)

Regards Charles

By the way Rolf thanks for the URL about Turbo Codes, just need to work out
how a
MAP decoder works now !

From Robert.Glassey@nmp.nokia.com Tue Oct 08 06:41:31 1996
Received: from noknic.nokia.com (noknic.nokia.com [131.228.6.10]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id GAA00633 for <hfsig@tapr.org>; Tue, 8 Oct 1996 06:41:02 -0500 (CDT)
From: Robert.Glassey@nmp.nokia.com
Received: from samail01.nmp.nokia.com (samail01.nmp.nokia.com [131.228.240.6]) by noknic.nokia.com (8.6.9/8.6.9) with ESMTP id NAA21819 for <hfsig@tapr.org>; Tue, 8 Oct 1996 13:40:21 +0200
Received: from  by samail01.nmp.nokia.com with SMTP
	(1.37.109.16/16.2) id AA213874835; Tue, 8 Oct 1996 14:40:35 +0300
X-Openmail-Hops: 2
Date: Tue, 8 Oct 96 12:37:05 +0100
Message-Id: <H0000292028bea99@MHS>
In-Reply-To: <199610071033.DAA22002@servo.qualcomm.com>
Subject: ARRL DCC and the old SS thread
Sender: Robert.Glassey@nmp.nokia.com
To: hfsig@tapr.org

> Warning: hot button alert!

> The proper measure of spectrum efficiency in a cellular environment is
> not QSOs per megahertz, but QSOs per megahertz PER SQUARE KILOMETER.
                                                **********************

> There's a very good reason (other than frequency stability and gain
> control reasons) why AMPS (analog) cellular uses FM instead of
> SSB. Thanks to its capture effect, FM can provide telephone quality
> audio with about 10-11 dB SNIR (signal-to-noise-plus-interference), as
> compared to about 25-30 dB for SSB.

I can't resist, sorry folks.

But I have to ARGEE with Phil :-)

SSB is more efficent for a single point to point link, at low audio
qualities, but in many cases, especialy celular, this is not the case.
Consider a celphone conversation where you could hear in the background
someone elses conversation! For the wanted signal signal to be 30dB
stronger, cells would need to be 10 time the diameter compared to FM
which needs only 10dB, and thus encloses 100 times the number of users,
so even if you can get 10 SSB users on a single FM channel, with FM you
could reuse the chanel so that you could actually fit 100 FM users on
the same channel in the same area, and with better audio quality, no
cross talk, and cheaper phones.

Digital modulatoin has a similar capture effect, but uses less bandwidth
than FM using standard compression (around 1/3), and half again with the
new 'half rate' compression. No only that, but the phone uses less
power, so you have longer talk times.

SS goes even further, allowing even more efficent modulation, even
better reuse, and even dynamic compresion to given even more channel
capacity.

I'd estimate SS would allow around 100 times the number of users in the
same area with better audio quality and more features than SSB. Spectral
efficency has got to be the *number one* reason for using SS in a
cellular enviroment!

And these benifits CAN be made to work for amateur radio too! But they
DON'T come for free.

Global HF radio could be compared to a huge single cell, and by breaking
it up into smaller cells, reducing power and using interference tolerant
systems such as SS, capacity could be dramatically increased, as in the
example of the SSB celular system. Because of the vagueities of HF
propagation the cellular structure would have to be dynamic but that's
within technological capability.

But the real question is not one of capacity, we have enough of that as
it is, the real question is one of USEFULLNESS. It becomes a question of
'what is amateur radio about anyway'. Of course it's about
experientation and learning, and even communication but that's more and
more becomming a secondary function since modern communication networks
are so good. So what use is the ham bands bands if you can only use a
single mode, over local distances, and only do things that you could do
much easier using the public networks? Maybe for the few who set up the
system it would be great, but how many hams in a million is that? There
would be so many aspects of ham radio that would be lost, that ham radio
would simply cease to exist, since its only remaining use would be
inferior to cheap public networks. Everyone who starts in radio must
start somewhere, end even though the older modes are outdated and well
behind the state of the art, they are simple and they are excelent for
anyone how wants to learn about radio, basic principles never go out of
date. You can learn a lot building and operating even a simple QRP CW
rig, and there's nothing to stop you using modern DDS chips, micro
controllers, power modules, RF IC's, etc etc. If I couldn't use RTTY
(because of hopping impulses say) as a simple starting mode for my
modem, BTL, I would have probably not even tried, now RTTY's going I can
move on to more up-to-date modes.

SS might be more efficent than narrow band modes, but it is more
efficent only when high power narrow band signals are excluded, and when
SS uses the band in a way that is incompatible to any other form of
amateur use of the bands, causing interference that it actually REDUCES
THE USEFULLNESS of the amateur bands. IF SS must be interference
resistant to get its capacity, then it MUST cause interference in
acheiving its capacity, and dispite its resistance it is still not
resistant enough to narrow band modes to acheive its capacity in their
presence.

Certinly if interference tolerant, power controled modes became the
norm, there would be many new applications that could use these modes,
but there would be no point in putting them on HF radio, since HF radio
would be reduced to the same coverage as conventional networks, but with
much poorer performance.

I'm afarid I'm still as convinced as ever that SS cannot co-exist with
narrow band modes, and the SS can never be the 'one true mode' in
amateur radio, if amateur radio is to exist at all. I welcome SS as a
new and fascinating facet of amateur radio, but am convinced that it
must be used only in exclusive SS bands, especially the microwave bands
where it is ideally suited to local, celular operation, and high,
competitive, data rates.

For those interested, a NEW SS band on HF would be fun, but SS cannot
presume to dictate to the rest of amateur radio.


Rob

Realisticaly PRO-SS!

Yes, I know there are SS sytems on HF & VHF already, but a few very wide
band systems a long way from most HF users is quite different to a
hundred SS users in every neighbourhood. Nothing is free, the band IS
used, and if the theoretical capacity of SS is realised, then the bands
will be just as heavilly loaded (apperaring to be more so to narrow band
users since they use the extra capacity to get the quality and distance
they expect). Even if it is only used as much as the bands are use right
now, the loading on the band will still be significant to non-
interference resistant modes.

From RLANIER@mailb.harris.com  Tue Oct 08 10:12:25 1996
Received: from sol.corp.Harris.COM (sol.corp.harris.com [137.237.25.4]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id KAA07196 for <hfsig@tapr.org>; Tue, 8 Oct 1996 10:12:20 -0500 (CDT)
Received: from mailb.harris.com by sol.corp.Harris.COM (8.6.12/Kurts Special version 2.0)
	id LAA03966; Tue, 8 Oct 1996 11:11:59 -0400
Received: from ccMail by mailb.harris.com
  (IMA Internet Exchange 1.04b) id 25a6ee50; Tue, 8 Oct 96 11:10:29 -0400
Mime-Version: 1.0
Date: Tue, 8 Oct 1996 11:09:18 -0400
Message-ID: <25a6ee50@mailb.harris.com>
From: RLANIER@mailb.harris.com (RLANIER)
Subject: Re: [HFSIG:1620] ARRL DCC and the old SS thread
To: hfsig@tapr.org
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part

     This discussion of SS is getting pretty old. I hope to soon have a 
     complete DSSS system built so I can put some of these issues to rest. 
     SS has been used, is being used now, and will be used in future, even 
     more than it is today. WHY? Because it works effectively WITHOUT 
     causing harmful interference.
     
     Keeping in mind that many companies are investing lots of money on 

     this subject. That alone should tell you something. If its not worth 
     doing, then why are they doing it?????????????
     
     There seems to be this pervasive paranoia about SS, almost as if its 
     "invading" amateur radio and its going to take control of all the 
     existing modes and strangle them out of existence!!! Man, some of you 
     people are RIDICULOUSLY PARANOID!!
     
     When the first high-speed SS network is built (and it will be built), 
     then we shall see the amount of interference . But you probably won't 
     know its there.
     
     73s de
     Tony,  KE4ATO


______________________________ Reply Separator _________________________________
Subject: [HFSIG:1620] ARRL DCC and the old SS thread
Author:  hfsig@tapr.org at smtp
Date:    10/8/96 6:56 AM


> Warning: hot button alert!
     
> The proper measure of spectrum efficiency in a cellular environment is 
> not QSOs per megahertz, but QSOs per megahertz PER SQUARE KILOMETER.
                                                **********************
     
> There's a very good reason (other than frequency stability and gain 
> control reasons) why AMPS (analog) cellular uses FM instead of
> SSB. Thanks to its capture effect, FM can provide telephone quality
> audio with about 10-11 dB SNIR (signal-to-noise-plus-interference), as 
> compared to about 25-30 dB for SSB.
     
I can't resist, sorry folks.
     
But I have to ARGEE with Phil :-)
     
SSB is more efficent for a single point to point link, at low audio 
qualities, but in many cases, especialy celular, this is not the case. 
Consider a celphone conversation where you could hear in the background 
someone elses conversation! For the wanted signal signal to be 30dB 
stronger, cells would need to be 10 time the diameter compared to FM 
which needs only 10dB, and thus encloses 100 times the number of users, 
so even if you can get 10 SSB users on a single FM channel, with FM you 
could reuse the chanel so that you could actually fit 100 FM users on 
the same channel in the same area, and with better audio quality, no 
cross talk, and cheaper phones.
     
Digital modulatoin has a similar capture effect, but uses less bandwidth 
than FM using standard compression (around 1/3), and half again with the 
new 'half rate' compression. No only that, but the phone uses less 
power, so you have longer talk times.
     
SS goes even further, allowing even more efficent modulation, even 
better reuse, and even dynamic compresion to given even more channel 
capacity.
     
I'd estimate SS would allow around 100 times the number of users in the 
same area with better audio quality and more features than SSB. Spectral 
efficency has got to be the *number one* reason for using SS in a 
cellular enviroment!
     
And these benifits CAN be made to work for amateur radio too! But they 
DON'T come for free.
     
Global HF radio could be compared to a huge single cell, and by breaking 
it up into smaller cells, reducing power and using interference tolerant 
systems such as SS, capacity could be dramatically increased, as in the 
example of the SSB celular system. Because of the vagueities of HF 
propagation the cellular structure would have to be dynamic but that's 
within technological capability.
     
But the real question is not one of capacity, we have enough of that as 
it is, the real question is one of USEFULLNESS. It becomes a question of 
'what is amateur radio about anyway'. Of course it's about 
experientation and learning, and even communication but that's more and 
more becomming a secondary function since modern communication networks 
are so good. So what use is the ham bands bands if you can only use a 
single mode, over local distances, and only do things that you could do 
much easier using the public networks? Maybe for the few who set up the 
system it would be great, but how many hams in a million is that? There 
would be so many aspects of ham radio that would be lost, that ham radio 

would simply cease to exist, since its only remaining use would be 
inferior to cheap public networks. Everyone who starts in radio must 
start somewhere, end even though the older modes are outdated and well 
behind the state of the art, they are simple and they are excelent for 
anyone how wants to learn about radio, basic principles never go out of 
date. You can learn a lot building and operating even a simple QRP CW 
rig, and there's nothing to stop you using modern DDS chips, micro 
controllers, power modules, RF IC's, etc etc. If I couldn't use RTTY 
(because of hopping impulses say) as a simple starting mode for my 
modem, BTL, I would have probably not even tried, now RTTY's going I can 
move on to more up-to-date modes.
     
SS might be more efficent than narrow band modes, but it is more 
efficent only when high power narrow band signals are excluded, and when 
SS uses the band in a way that is incompatible to any other form of 
amateur use of the bands, causing interference that it actually REDUCES 
THE USEFULLNESS of the amateur bands. IF SS must be interference 
resistant to get its capacity, then it MUST cause interference in 
acheiving its capacity, and dispite its resistance it is still not 
resistant enough to narrow band modes to acheive its capacity in their 
presence.
     
Certinly if interference tolerant, power controled modes became the 
norm, there would be many new applications that could use these modes, 
but there would be no point in putting them on HF radio, since HF radio 
would be reduced to the same coverage as conventional networks, but with 
much poorer performance.
     
I'm afarid I'm still as convinced as ever that SS cannot co-exist with 
narrow band modes, and the SS can never be the 'one true mode' in 
amateur radio, if amateur radio is to exist at all. I welcome SS as a 
new and fascinating facet of amateur radio, but am convinced that it 
must be used only in exclusive SS bands, especially the microwave bands 
where it is ideally suited to local, celular operation, and high, 
competitive, data rates.
     
For those interested, a NEW SS band on HF would be fun, but SS cannot 
presume to dictate to the rest of amateur radio.
     
     
Rob
     
Realisticaly PRO-SS!
     
Yes, I know there are SS sytems on HF & VHF already, but a few very wide 
band systems a long way from most HF users is quite different to a 
hundred SS users in every neighbourhood. Nothing is free, the band IS 
used, and if the theoretical capacity of SS is realised, then the bands 
will be just as heavilly loaded (apperaring to be more so to narrow band 
users since they use the extra capacity to get the quality and distance 
they expect). Even if it is only used as much as the bands are use right 
now, the loading on the band will still be significant to non- 
interference resistant modes.
     

From Robert.Glassey@nmp.nokia.com Tue Oct 08 12:56:13 1996
Received: from noknic.nokia.com (noknic.nokia.com [131.228.6.10]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id MAA16308 for <hfsig@tapr.org>; Tue, 8 Oct 1996 12:56:11 -0500 (CDT)
From: Robert.Glassey@nmp.nokia.com
Received: from samail01.nmp.nokia.com (samail01.nmp.nokia.com [131.228.240.6]) by noknic.nokia.com (8.6.9/8.6.9) with ESMTP id TAA05831 for <hfsig@tapr.org>; Tue, 8 Oct 1996 19:55:37 +0200
Received: from  by samail01.nmp.nokia.com with SMTP
	(1.37.109.16/16.2) id AA171987350; Tue, 8 Oct 1996 20:55:51 +0300
X-Openmail-Hops: 2
Date: Tue, 8 Oct 96 18:52:27 +0100
Message-Id: <H0000292028d5122@MHS>
In-Reply-To: <25a6ee50@mailb.harris.com>
Subject: [HFSIG:1621] Re: ARRL DCC and the old SS thread
Sender: Robert.Glassey@nmp.nokia.com
To: hfsig@tapr.org

> WHY? Because it [SS] works effectively WITHOUT causing harmful
> interference.


This statement needs to be qualified. It DOES work in MANY cases without
harmfull interference, but the definition of 'harmfull' is highly
dependent of the application and many other factors such as processing
gain, propagation and encumbant applications.

Are there any successfull high speed SS systems that operate for example
on the aeronaughtical VHF band near an airport with a range of several
miles, and several dozon similtainious users? My point is that existing
applications have chosen their circumstances for a reason.

You don't get something for nothing, SS does not work by magic, it must
still obey the laws of physics. It's a question of whether what you use
will be missed.

Best of luck with your design, but there is potential for problems, and
these are best overcome by forseeing them and designing the system
around them. Its best not to design on blind faith. How will you
overcome the problems of powerfull, nearby uncontrolled transmitters and
nearby hidden receivers? Perhaps it just 'wont happen here'? Most
systems rely on high processing gains, or short ranges, or channel
hopping, or sole use of a band, or expect other users to be interference
resistant. Whats the right mix for the band you will use? These choices
will make or break a SS system, and if you intend widespread use, they
are of even greater importance. Do you think designers of the various
sucessfull systems ignored these considerations? Applying these
considerations to the amateur HF situation gives a pretty grim picture,
when the zealistic euphoria subsides.


Rob

From cn1743@coastalnet.com Tue Oct 08 14:07:13 1996
Received: from lucky.coastalnet.com (abaco.coastalnet.com [204.183.40.2]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id OAA18435 for <hfsig@tapr.org>; Tue, 8 Oct 1996 14:07:12 -0500 (CDT)
Received: from louis-dupree (pm-knst2-54.coastalnet.com [204.183.47.54]) by lucky.coastalnet.com (8.6.12/8.6.12) with SMTP id PAA25987 for <hfsig@tapr.org>; Tue, 8 Oct 1996 15:06:16 -0400
Message-Id: <2.2.32.19961008190704.00683b4c@abaco.coastalnet.com>
X-Sender: cn1743@abaco.coastalnet.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 08 Oct 1996 15:07:04 -0400
To: hfsig@tapr.org
From: Louis Dupree <cn1743@coastalnet.com>
Subject: Unsubscribe

How do I unsubscribe from this ? I tried and says I am not listed as having
subscribed. I am going to be away for a while and  not sure how much email
my ISP wil hold for me. I can then re-subscribe when I get back. Thank you.
Louis



Louis J. Dupree Jr.
3015 Englewood Dr.
Kinston, NC 28504
ldupree@coastalnet.com

From RLANIER@mailb.harris.com  Tue Oct 08 16:50:04 1996
Received: from sol.corp.Harris.COM (sol.corp.harris.com [137.237.25.4]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id QAA25120 for <hfsig@tapr.org>; Tue, 8 Oct 1996 16:50:02 -0500 (CDT)
Received: from mailb.harris.com by sol.corp.Harris.COM (8.6.12/Kurts Special version 2.0)
	id RAA03546; Tue, 8 Oct 1996 17:49:56 -0400
Received: from ccMail by mailb.harris.com
  (IMA Internet Exchange 1.04b) id 25acc2a0; Tue, 8 Oct 96 17:48:26 -0400
Mime-Version: 1.0
Date: Tue, 8 Oct 1996 17:47:12 -0400
Message-ID: <25acc2a0@mailb.harris.com>
From: RLANIER@mailb.harris.com (RLANIER)
Subject: Re: [HFSIG:1622] Re: ARRL DCC and the old SS thread
To: hfsig@tapr.org
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part

     I don't think SS works by magic - quite the opposite. What I get tired 
     of hearing is this notion that SS will cause widespread interference. 
     If run at 1500 watts, of course it will!!! But using automatic power 
     control and proper design techniques, which most home brewers follow 
     anyway, SS will not be this giant "killer" of the amateur bands.
     
     Some hams are already using high-speed networks in various parts of 
     the country and with good success. Why not use SS as well?? Of course 
     there are obstacles to overcome - EVERY system has to do that. And 
     hams CAN do it if we stop arguing about!!
     
     I will continue to experiment with SS because I know it has a future. 
     And if no one else wants to design a high-speed network, then I'll do 
     it. 
     
     And then start my own company ...
     
     73s de
     Tony,  KE4ATO


______________________________ Reply Separator _________________________________
Subject: [HFSIG:1622] Re: ARRL DCC and the old SS thread
Author:  hfsig@tapr.org at smtp
Date:    10/8/96 12:57 PM


> WHY? Because it [SS] works effectively WITHOUT causing harmful 
> interference.
     
This statement needs to be qualified. It DOES work in MANY cases without 
harmfull interference, but the definition of 'harmfull' is highly 
dependent of the application and many other factors such as processing 
gain, propagation and encumbant applications.
     
Are there any successfull high speed SS systems that operate for example 
on the aeronaughtical VHF band near an airport with a range of several 
miles, and several dozon similtainious users? My point is that existing 
applications have chosen their circumstances for a reason.
     
You don't get something for nothing, SS does not work by magic, it must 
still obey the laws of physics. It's a question of whether what you use 
will be missed.
     
Best of luck with your design, but there is potential for problems, and 
these are best overcome by forseeing them and designing the system 
around them. Its best not to design on blind faith. How will you 
overcome the problems of powerfull, nearby uncontrolled transmitters and 
nearby hidden receivers? Perhaps it just 'wont happen here'? Most 
systems rely on high processing gains, or short ranges, or channel 
hopping, or sole use of a band, or expect other users to be interference 
resistant. Whats the right mix for the band you will use? These choices 
will make or break a SS system, and if you intend widespread use, they 
are of even greater importance. Do you think designers of the various 
sucessfull systems ignored these considerations? Applying these 
considerations to the amateur HF situation gives a pretty grim picture, 
when the zealistic euphoria subsides.
     
     
Rob
     

From karn@qualcomm.com Wed Oct 09 04:19:01 1996
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id EAA24363 for <hfsig@tapr.org>; Wed, 9 Oct 1996 04:18:58 -0500 (CDT)
Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id CAA27573; Wed, 9 Oct 1996 02:18:25 -0700 (PDT)
Date: Wed, 9 Oct 1996 02:18:25 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199610090918.CAA27573@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <H0000292028bea99@MHS> (Robert.Glassey@nmp.nokia.com)
Subject: Re: [HFSIG:1620] ARRL DCC and the old SS thread

Since it seems the SS issue is coming up again, I'd like to address it
in the larger context of where ham radio is going and where I think it
has gotten off the track in the 25 years I've been licensed (I qualify
for QCWA in November -- gotta sign up!)

>Global HF radio could be compared to a huge single cell, and by breaking

Depends on the band. Even 20m propagation is rarely worldwide -- skip
zones and the like work to break it up. And propagation is decidedly
regional on 40m and below, especially during the day. Reuse can and
does take place on the HF bands. And it's in a reuse environment that
SS really shines.

>are so good. So what use is the ham bands bands if you can only use a
>single mode, over local distances, and only do things that you could do
>much easier using the public networks? Maybe for the few who set up the

The same question could be asked for SSB and CW. What use is ham radio
if not only have its public service aspects been rendered obsolete by
advances in commercial communications, but the technology and amateur
skill-set have also remained totally stagnant, 20 years and counting
behind the commercial state of the art?

My basic philosophy in ham radio has always been to build open systems
that can be taken apart, learned from, modified and improved by anyone
who feels like it. I'm very disturbed by an almost complete conversion
of the amateur market during the time I've been a ham to impenetrable,
proprietary "black boxes".

In the old days one could expect the manual for any piece of gear
you'd buy to include a complete schematic, as well as a comprehensive
theory-of-operation section. Heathkits were the best. I used to spend
hours poring over those schematics, learning whatever I could. I think
I've always spent more time (and had more fun) doing that than
actually operating the equipment!

I think the trend to the black box started when microprocessors first
appeared in amateur gear. By itself this was a very good development,
as writing and modifying software is an almost ideal ham activity; the
capital costs are minimal compared to hardware, and the results are
easily shared.

But I don't know of a single major ham manufacturer that prints the
microprocessor source code for their transceivers in the manual.  They
continued to provide schematics, but more and more of the
functionality was now performed inside an impenetrable rectangle
marked "CPU".

Even TAPR, an organization otherwise remarkable for its openness and
commitment to amateur education, treated the source code to its TNCs
as proprietary and gave it out only under license to manufacturers who
paid substantial fees.

And now we have three major HF digital modes, Clover II, Pactor II and
G-TOR. Not only are they all implemented solely in black boxes with
unpublished source code, but even the modulation schemes themselves
are largely unpublished. (At least the AX.25 protocol implemented by the
proprietary TAPR TNC code was published).

Even worse, at least two of the three (Clover and G-TOR) are covered
by granted or pending patents -- the absolute antithesis of the
cooperative amateur spirit. (I've seen the Clover patent.  As with
most patents today, it describes only one tiny aspect of the real
product -- the use of sequential carriers to combat ISI -- and gives
almost no insight into the complete system. It apparently remains a
trade secret.)

To be sure, this only mimics the usual practice in the commercial
radio industry -- every Part 15.247 device I know of is a proprietary
black box, heavily covered by patents. And many of them are crap (both
the radios and the patents!)

I feel strongly that if ham radio is to come close to justifying its
existence, we need to develop new modulation modes AND we must do it
in a totally open, cooperative, GNU-like fashion. All waveform designs
and source code made freely available, at least for amateur radio
uses.

In other words, the goal of ham radio isn't just to develop and deploy
the most advanced radio modulation techniques possible. That's already
going on outside ham radio with far more talent and resources than we
can possibly bring to bear. And you don't need a ham license to use
them.

No, the real reason to develop and deploy new technologies in the
amateur service is to make it possible for anyone interested to
participate and perhaps learn something in the process.

No amateur would be forced to get his hands dirty with the details of
spread spectrum, coding or whatever, and I am under no illusions that
more than a small percentage of hams will want to. But it is vitally
important to encourage that small percentage, because *they* will
almost single-handedly justify ham radio's continued existence -- not
the DXers, contesters or rag-chewers. Not that I have anything against
those activites. But they simply won't pay the rent anymore.

So this means we have to do three things:

1. Set an example by designing and producing open, fully documented
modulation schemes and the hardware and software to implement them,
and encourage any interested parties to experiment, modify, contribute
and learn;

2. Lobby for more rational licensing requirements that emphasize the
increasing importance of relevant technical expertise in ham radio
(i.e., abolishing the CW test for all license classes);

3. Lobby for the least restrictive rules possible for emission modes,
bandwidths, etc, delegating all intra-service interference issues to
the hams themselves instead of hard-coding them in the FCC rules.

I won't make any guarantees that no one will ever suffer interference
from an experimental SS system. But who ever said we're entitled to
any guarantees at all? I consider it a challenge to work these things
out for ourselves. The FCC rules already let us do lots of things in
theory that clearly could interfere with other amateurs, such as
running 1.5KW of FM in the middle of the 2m satellite band. But by and
large most hams are willing to cooperate, foregoing something that is
technically legal in order to help another ham. (The few that don't
cooperate probably also ignore FCC rules anyway!) 

Voluntary bandplans and gentlemen's agreements already exist on many
bands to promote a plurality of modes, and I'm confident that they can
be adapted to deal with spread spectrum. As can novel newer methods
for mitigating interference, such my idea of a standard narrowband
packet channel for dynamic local interference resolution. (If somebody
nearby is QRMing you on a particular frequency, you complain on the
packet channel and the interfering transmitter automatically QSYs,
QRPs or shuts up. Think of it as a general form of busy tone multiple
access.)

We're not directing air traffic, and we're not dispatching ambulance
and police services. We *are* supposed to be technical experimenters,
teachers and students. And if we aren't, we'll soon be nothing at all.

Phil

From jsanford@infi.net Wed Oct 09 06:05:37 1996
Received: from mh004.infi.net (mh004.infi.net [198.22.1.119]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id GAA26331 for <hfsig@tapr.org>; Wed, 9 Oct 1996 06:05:35 -0500 (CDT)
Received: from PENTIUM by mh004.infi.net with SMTP 
	(Infinet-S-3.3) id HAA30946; Wed, 9 Oct 1996 07:05:42 -0400 (EDT)
Message-ID: <325B8712.234B@infi.net>
Date: Wed, 09 Oct 1996 07:05:54 -0400
From: Jim Sanford <jsanford@infi.net>
Reply-To: wb4gcs@amsat.org
Organization: WB4GCS
X-Mailer: Mozilla 3.0 (Win16; U)
MIME-Version: 1.0
To: hfsig@tapr.org
Subject: Re: [HFSIG:1625] Re: ARRL DCC and the old SS thread
References: <199610090918.CAA27573@servo.qualcomm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Phil Karn wrote:
> 

> But I don't know of a single major ham manufacturer that prints the
> microprocessor source code for their transceivers in the manual.  They
> continued to provide schematics, but more and more of the
> functionality was now performed inside an impenetrable rectangle
> marked "CPU".
And some badly need improvement, like the documented problems with the
Yaesu 736R, and it's obsolescent, limited computer command set.


> And now we have three major HF digital modes, Clover II, Pactor II and
> G-TOR. Not only are they all implemented solely in black boxes with
> unpublished source code, but even the modulation schemes themselves
> are largely unpublished. (At least the AX.25 protocol implemented by the
> proprietary TAPR TNC code was published).
Which is why I refuse to subsidize their greed (and use of paying hams
to
beta test stuff they really want to sell to the military) by buying
their
stuff.
> 
> Even worse, at least two of the three (Clover and G-TOR) are covered
> by granted or pending patents -- the absolute antithesis of the
> cooperative amateur spirit. (I've seen the Clover patent.  As with
> most patents today, it describes only one tiny aspect of the real
> product -- the use of sequential carriers to combat ISI -- and gives
> almost no insight into the complete system. It apparently remains a
> trade secret.)
See recent issues of Dr. Dobb's Journal and C/C++ Users Group Magazines
for alarming and depressing news on the whole "software patents" issue.
Scary.

 
> I feel strongly that if ham radio is to come close to justifying its
> existence, we need to develop new modulation modes AND we must do it
> in a totally open, cooperative, GNU-like fashion. All waveform designs
> and source code made freely available, at least for amateur radio
> uses.
AMEN!  Thank you and Johan for all that you're doing, openly.
> 
> 1. Set an example by designing and producing open, fully documented
> modulation schemes and the hardware and software to implement them,
> and encourage any interested parties to experiment, modify, contribute
> and learn;
> 
AMEN
Phil:  As usual, well said.

73, Jim
wb4gcs@amsat.org

From n4cnw@ibm.net Wed Oct 09 06:34:04 1996
Received: from smtp-gw01.ny.us.ibm.net (smtp-gw01.ny.us.ibm.net [165.87.194.252]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id GAA27148 for <hfsig@tapr.org>; Wed, 9 Oct 1996 06:34:02 -0500 (CDT)
Received: (from uucp@localhost) by smtp-gw01.ny.us.ibm.net (8.6.9/8.6.9) id LAA88041 for <hfsig@tapr.org>; Wed, 9 Oct 1996 11:33:59 GMT
Received: from s402446.orl.mmc.com(141.240.136.233) by smtp-gw01.ny.us.ibm.net via smap (V1.3mjr)
	id smaIqEDM2; Wed Oct  9 11:33:42 1996
Message-ID: <325B8E72.45F3@ibm.net>
Date: Wed, 09 Oct 1996 07:37:22 -0400
From: Mike Murphree <n4cnw@ibm.net>
Organization: MadCat Inc
X-Mailer: Mozilla 2.02 (Win16; I)
MIME-Version: 1.0
To: hfsig@tapr.org
Subject: Re: [HFSIG:1623] Unsubscribe
References: <2.2.32.19961008190704.00683b4c@abaco.coastalnet.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Louis Dupree wrote:
> 
> How do I unsubscribe from this ? I tried and says I am not listed as having
> subscribed. I am going to be away for a while and  not sure how much email
> my ISP wil hold for me. I can then re-subscribe when I get back. Thank you.
> Louis
> 
> Louis J. Dupree Jr.
> 3015 Englewood Dr.
> Kinston, NC 28504
> ldupree@coastalnet.com

Just yesterday I saw a similar case where I was subscribed twice to
the same list under two different email addresses that would get
delivered to the same account, i.e. my previous provider uses both
of the following domains: pig.net and praxis.net. The fix in this
case was to find a mailer that explicitly defined the "From" field
in the headers and didn't let it default to what the provider picks
as default and unsubscribe with the proper address.

73
Mike N4CNW

From RLANIER@mailb.harris.com  Wed Oct 09 07:52:03 1996
Received: from sol.corp.Harris.COM (sol.corp.harris.com [137.237.25.4]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id HAA29458 for <hfsig@tapr.org>; Wed, 9 Oct 1996 07:52:01 -0500 (CDT)
Received: from mailb.harris.com by sol.corp.Harris.COM (8.6.12/Kurts Special version 2.0)
	id IAA08625; Wed, 9 Oct 1996 08:51:52 -0400
Received: from ccMail by mailb.harris.com
  (IMA Internet Exchange 1.04b) id 25b9f7e0; Wed, 9 Oct 96 08:50:06 -0400
Mime-Version: 1.0
Date: Wed, 9 Oct 1996 08:46:34 -0400
Message-ID: <25b9f7e0@mailb.harris.com>
From: RLANIER@mailb.harris.com (RLANIER)
Subject: Re: [HFSIG:1625] Re: ARRL DCC and the old SS thread
To: hfsig@tapr.org
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part

     The reason so many companies (and I assume TAPR as well) make software 
     proprietary is to protect their product. You have to look at it from 
     their point of view: a group or an individual has worked hard to 
     produce a working product and they certainly DO NOT want another 
     company or individual stealing that idea. This is a very real 
     possibility because we live in a VERY competitive world. Giving out 
     your secrets is like committing suicide.
     
     I can understand your frustrating, but believe me, if you had worked 
     on a project only to see your competitor come out with a product with 
     the same thing you had worked on, you would understand what I am 
     talking about.
     
     Remember, companies are in the business to make money, not share their 
     secrets with those who are curious!
     
     73s de
     Tony,  KE4ATO
     
     
     
     
     
In the old days one could expect the manual for any piece of gear 
you'd buy to include a complete schematic, as well as a comprehensive 
theory-of-operation section. Heathkits were the best. I used to spend 
hours poring over those schematics, learning whatever I could. I think 
I've always spent more time (and had more fun) doing that than 
actually operating the equipment!
     
I think the trend to the black box started when microprocessors first 
appeared in amateur gear. By itself this was a very good development, 
as writing and modifying software is an almost ideal ham activity; the 
capital costs are minimal compared to hardware, and the results are 
easily shared.
     
But I don't know of a single major ham manufacturer that prints the 
microprocessor source code for their transceivers in the manual.  They 
continued to provide schematics, but more and more of the 
functionality was now performed inside an impenetrable rectangle 
marked "CPU".
     
Even TAPR, an organization otherwise remarkable for its openness and 
commitment to amateur education, treated the source code to its TNCs 
as proprietary and gave it out only under license to manufacturers who 
paid substantial fees.
     
And now we have three major HF digital modes, Clover II, Pactor II and 
G-TOR. Not only are they all implemented solely in black boxes with 
unpublished source code, but even the modulation schemes themselves
are largely unpublished. (At least the AX.25 protocol implemented by the 
proprietary TAPR TNC code was published).
     
Even worse, at least two of the three (Clover and G-TOR) are covered 
by granted or pending patents -- the absolute antithesis of the 
cooperative amateur spirit. (I've seen the Clover patent.  As with 
most patents today, it describes only one tiny aspect of the real 
product -- the use of sequential carriers to combat ISI -- and gives 
almost no insight into the complete system. It apparently remains a 
trade secret.)
     
To be sure, this only mimics the usual practice in the commercial 
radio industry -- every Part 15.247 device I know of is a proprietary 
black box, heavily covered by patents. And many of them are crap (both 
the radios and the patents!)
     
I feel strongly that if ham radio is to come close to justifying its 
existence, we need to develop new modulation modes AND we must do it 
in a totally open, cooperative, GNU-like fashion. All waveform designs 
and source code made freely available, at least for amateur radio 
uses.
     
In other words, the goal of ham radio isn't just to develop and deploy 
the most advanced radio modulation techniques possible. That's already 
going on outside ham radio with far more talent and resources than we 
can possibly bring to bear. And you don't need a ham license to use 
them.
     
No, the real reason to develop and deploy new technologies in the 
amateur service is to make it possible for anyone interested to 
participate and perhaps learn something in the process.
     
No amateur would be forced to get his hands dirty with the details of 
spread spectrum, coding or whatever, and I am under no illusions that 
more than a small percentage of hams will want to. But it is vitally 
important to encourage that small percentage, because *they* will 
almost single-handedly justify ham radio's continued existence -- not 
the DXers, contesters or rag-chewers. Not that I have anything against 
those activites. But they simply won't pay the rent anymore.
     
So this means we have to do three things:
     
1. Set an example by designing and producing open, fully documented 
modulation schemes and the hardware and software to implement them, and 
encourage any interested parties to experiment, modify, contribute and 
learn;
     
2. Lobby for more rational licensing requirements that emphasize the 
increasing importance of relevant technical expertise in ham radio 
(i.e., abolishing the CW test for all license classes);
     
3. Lobby for the least restrictive rules possible for emission modes, 
bandwidths, etc, delegating all intra-service interference issues to 
the hams themselves instead of hard-coding them in the FCC rules.
     
I won't make any guarantees that no one will ever suffer interference 
from an experimental SS system. But who ever said we're entitled to 
any guarantees at all? I consider it a challenge to work these things 
out for ourselves. The FCC rules already let us do lots of things in 
theory that clearly could interfere with other amateurs, such as 
running 1.5KW of FM in the middle of the 2m satellite band. But by and 
large most hams are willing to cooperate, foregoing something that is 
technically legal in order to help another ham. (The few that don't 
cooperate probably also ignore FCC rules anyway!) 
     
Voluntary bandplans and gentlemen's agreements already exist on many 
bands to promote a plurality of modes, and I'm confident that they can 
be adapted to deal with spread spectrum. As can novel newer methods for 
mitigating interference, such my idea of a standard narrowband packet 
channel for dynamic local interference resolution. (If somebody nearby 
is QRMing you on a particular frequency, you complain on the packet 
channel and the interfering transmitter automatically QSYs, QRPs or 
shuts up. Think of it as a general form of busy tone multiple access.)
     
We're not directing air traffic, and we're not dispatching ambulance 
and police services. We *are* supposed to be technical experimenters, 
teachers and students. And if we aren't, we'll soon be nothing at all.
     
Phil
     

From k5yfw@www.kelly-afb.org Wed Oct 09 08:19:20 1996
Received: from www.kelly-afb.org (www.kelly-afb.org [204.214.204.10]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id IAA00547 for <hfsig@tapr.org>; Wed, 9 Oct 1996 08:19:18 -0500 (CDT)
Received: (from k5yfw@localhost) by www.kelly-afb.org (8.7.1/8.7.1) id IAA16110; Wed, 9 Oct 1996 08:20:14 -0500 (CDT)
From: Walt DuBose - K5YFW <k5yfw@www.kelly-afb.org>
Message-Id: <199610091320.IAA16110@www.kelly-afb.org>
Subject: Re: [HFSIG:1626] Re: ARRL DCC and the old SS thread
To: hfsig@tapr.org
Date: Wed, 9 Oct 1996 08:20:14 -0500 (CDT)
In-Reply-To: <325B8712.234B@infi.net> from "Jim Sanford" at Oct 9, 96 06:19:27 am
Reply-To: k5yfw@www.kelly-afb.org
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text

In Jim's message he write:
> 
> Phil Karn wrote:
[stuff deleted]
> Which is why I refuse to subsidize their greed (and use of paying hams
> to beta test stuff they really want to sell to the military) by buying
> their stuff. 

	Sorry Jim, I don't think they made their boxes for the Military
	as the U.S., Nato and SE Asia militaries have better modems for
	HF (and most are using them) than G-TOR, PACTOR-II or CLOVER II
	have to offer.  The MIL-STD (and Nato STD) is 4800/2400 BPS with
	Reed-Soloman coding FEC, etc (MIL-STD 188-110c and later).  There
	are other MIL-STDs that also cover HF modems that are a bit different
	than 188-110c.

> > 
> > Even worse, at least two of the three (Clover and G-TOR) are covered
> > by granted or pending patents -- the absolute antithesis of the
> > cooperative amateur spirit. 
[stuff deleted]
>  
> > I feel strongly that if ham radio is to come close to justifying its
> > existence, we need to develop new modulation modes AND we must do it
> > in a totally open, cooperative, GNU-like fashion. All waveform designs
> > and source code made freely available, at least for amateur radio
> > uses.
	
	AMEN and AMEN!

	And I might add, we need to have these "run", if externally, 
	on boards like the TI and Motorola DSP boards and/or on
	platforms like the TAPR DPS box. Or, to keep Phil happy,
	run it all in software.

	I think two thinks will happen if we do the above.  One the
	"experimentar/bulder" will take the "board" and make his own
	computer/radio interface. Second, the OFs, like me, who can't see
	to build anymore, will buy the board and interface from guys like
	Gwyn Reedy.  And everybody will be happy...even the League because
	they can include a "real" construction project in the ARRL Manual.

> >
> AMEN!  Thank you and Johan for all that you're doing, openly.
> > 
> > 1. Set an example by designing and producing open, fully documented
> > modulation schemes and the hardware and software to implement them,
> > and encourage any interested parties to experiment, modify, contribute
> > and learn;
> > 
> AMEN
> Phil:  As usual, well said.
> 
> 73, Jim
> wb4gcs@amsat.org
> 

	As that old black deacon from Waco, Texas used to say...
	"Preach on brother, ya gotta an audiance".

73,

Walt/K5YFW

From gwyn@paccomm.com Wed Oct 09 11:55:22 1996
Received: from paccomm.com (paccomm.com [163.125.30.1]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id LAA07796 for <hfsig@tapr.org>; Wed, 9 Oct 1996 11:55:16 -0500 (CDT)
Received: from gwyn.paccomm.com by paccomm.com with smtp
	(Smail3.1.29.1 #1) id m0vB1uf-000FQLC; Wed, 9 Oct 96 12:55 EDT
Received: by gwyn.paccomm.com with Microsoft Mail
	id <01BBB5E1.791C7DC0@gwyn.paccomm.com>; Wed, 9 Oct 1996 12:57:48 -0400
Message-ID: <01BBB5E1.791C7DC0@gwyn.paccomm.com>
From: Gwyn Reedy <gwyn@paccomm.com>
To: "'hfsig@tapr.org'" <hfsig@tapr.org>
Subject: Why things are the way they are
Date: Wed, 9 Oct 1996 12:57:46 -0400
Encoding: 114 TEXT

Jim Sanford[SMTP:jsanford@infi.net] said, quoting Phil Karn:

>>Phil Karn wrote:
>>
>>
>> But I don't know of a single major ham manufacturer that prints the
>> microprocessor source code for their transceivers in the manual.  They
>> continued to provide schematics, but more and more of the
>> functionality was now performed inside an impenetrable rectangle
>> marked "CPU".
>
>And some badly need improvement, like the documented problems with the
>Yaesu 736R, and it's obsolescent, limited computer command set.
>
>
>> And now we have three major HF digital modes, Clover II, Pactor II and
>> G-TOR. Not only are they all implemented solely in black boxes with
>> unpublished source code, but even the modulation schemes themselves
>> are largely unpublished. (At least the AX.25 protocol implemented by the
>> proprietary TAPR TNC code was published).
>
>Which is why I refuse to subsidize their greed (and use of paying hams to
>beta test stuff they really want to sell to the military) by buying their 
stuff.
>
>
>> Even worse, at least two of the three (Clover and G-TOR) are covered
>> by granted or pending patents -- the absolute antithesis of the
>> cooperative amateur spirit. (I've seen the Clover patent.  As with
>> most patents today, it describes only one tiny aspect of the real
>> product -- the use of sequential carriers to combat ISI -- and gives
>> almost no insight into the complete system. It apparently remains a
>> trade secret.)
>
>See recent issues of Dr. Dobb's Journal and C/C++ Users Group Magazines
f>or alarming and depressing news on the whole "software patents" issue.
>Scary.
>
>
>> I feel strongly that if ham radio is to come close to justifying its
>> existence, we need to develop new modulation modes AND we must do it
>> in a totally open, cooperative, GNU-like fashion. All waveform designs
>> and source code made freely available, at least for amateur radio
>> uses.

>AMEN!  Thank you and Johan for all that you're doing, openly.
>
>> 1. Set an example by designing and producing open, fully documented
>> modulation schemes and the hardware and software to implement them,
>> and encourage any interested parties to experiment, modify, contribute
>> and learn;
>
>AMEN
>Phil:  As usual, well said.
>
>73, Jim
>wb4gcs@amsat.org


I feel the need to comment on Jim's greed comment. These comments are as 
owner of one of the smaller manufacturing outfits and a long time ham 
(Phil, I've only got 8 years till I qualify for Double QCWA).

First, I generally agree with most of Phil Karn's comments about the future 
of ham radio and the attitudes and conditions which now exist that impede 
progress.  I do what I can to aid progress. Phil is extremely generous with 
the results of his labors, but I would point out to Phil that he earns a 
living at a large firm, and doesn't suggest that they should give their 
product away.

While my company was not singled out as perpetrator of the situation 
mentioned, we could have been. I would only hope that people would make 
judgements on an individual basis, and not indulge in group condemnation. 
And to do that, they need additional information. Licenses, confidentiality 
agreements, etc. limit what a company may do, even if they want to.

Secondly, I would hope that people could see beyond the (to me - false) 
perception that amateurs are somehow being victimized by companies which 
produce equipment for their use. Do you also feel victimized by your 
automobile or washing machine manufacturer? If not, then why by amateur 
equipment manufacturers? (If yes, then see your analyst.)

Perhaps my real bitch is what I perceive as the widespread lack of economic 
understanding in the amateur community and the American population in 
general. Having the costs of production and sales available to me certainly 
assures me that we are not operating in the realm of greed. Without 
publishing our entire financial statement, how does one convince someone 
else that they are not being ripped-off ?

If you live on a farm or grow a garden, you are probably upset about the 
food prices in grocery stores. You know how little you get paid for your 
product or how little it costs to grow (and you ignore the value of your 
time and labor). But people pay for convenience - local stores open 24 
hours etc. The stores would go out of business if everyone made a garden, 
BUT THEY DON'T. And if they did, you would see much simpler food on the 
table.

Similarly, amateur equipment manufacturers exist because there is a market 
for what they produce at the price they charge. (And like farmers, they 
don't make much on it.) If there were no amateur manufacturers, there would 
be a lot more construction and experimenting, but much less of amateur 
radio in general. (Not sure that is bad, but that is another whole subject, 
as inappropriate for HFSIG as this message is, HI).

I don't mean to waste people's time reading this (nor to 'waste bandwidth' 
 a wretched phrase) and certainly don't want to start a flame war. I just 
want to see more thoughtfulness and less shooting from the hip or 
conspiracy based comments.

Thank you for reading this.

Gwyn Reedy, W1BEL
PacComm Packet Radio Systems
http://www.paccomm.com

From rwilliam@cesa4.k12.wi.us Wed Oct 09 15:00:44 1996
Received: from gomer.wiscnet.net (dial.wiscnet.net [144.92.88.11]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id PAA14358 for <hfsig@tapr.org>; Wed, 9 Oct 1996 15:00:42 -0500 (CDT)
Received: from RICKWILLIAMS by gomer.wiscnet.net;
          id PAA484744; 8.6.9W/50; Wed, 9 Oct 1996 15:00:29 -0500
Message-Id: <199610092000.PAA484744@gomer.wiscnet.net>
From: "Rick Williams" <rwilliam@cesa4.k12.wi.us>
To: <hfsig@tapr.org>
Subject: Re: [HFSIG:1630] Why things are the way they are
Date: Wed, 9 Oct 1996 14:58:24 -0500
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


Gwyn Reedy had commented:

> Perhaps my real bitch is what I perceive as the widespread lack of
economic 
> understanding in the amateur community and the American population in 
> general. Having the costs of production and sales available to me
certainly 
> assures me that we are not operating in the realm of greed. Without 
> publishing our entire financial statement, how does one convince someone 
> else that they are not being ripped-off ?
> 
I do have seen this lack of understanding in the general population where
folks dont have much of a grasp of the way the world works. But it really
pains me when I see it in the amateur community who I like to think of as
at least a little more knowledgeable. 

Most comments about other peoples greed are a reflection of the very
individual's own
greed (as it is with most negative comments about others). Those
individuals who use this kind of language, rarely work for free themselves
and often expect very nice salaries for the work they do.

But I heartily concur, that as a group, the amateur community should
embrace new methods of communication and that is not happening. ARRL
certainly has done little to promote this and the only organization that
seems to be somewhat in that direction is TAPR. 

My limited experience several years ago to try and get people excited about
new "high speed" digital was not appreciated very much. So there are
probably others like me who now sit on the sidelines and view what is going
on and hope for some direction from our ham organizations. 

Rick, KV9U


From wd5ivd@tapr.org Wed Oct 09 15:56:00 1996
Received: (from wd5ivd@localhost) by tapr.org (8.7.5/8.7.3/1.9) id PAA16268 for hfsig@tapr.org; Wed, 9 Oct 1996 15:56:00 -0500 (CDT)
From: Greg Jones <wd5ivd@tapr.org>
Message-Id: <199610092056.PAA16268@tapr.org>
Subject: Re: [HFSIG:1628] Re: ARRL DCC and the old SS thread
To: hfsig@tapr.org
Date: Wed, 9 Oct 1996 15:55:59 -0500 (CDT)
In-Reply-To: <25b9f7e0@mailb.harris.com> from "RLANIER" at Oct 9, 96 07:56:47 am
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

>      
> Even TAPR, an organization otherwise remarkable for its openness and 
> commitment to amateur education, treated the source code to its TNCs 
> as proprietary and gave it out only under license to manufacturers who 
> paid substantial fees.

The reason for this is simple -- TAPR does not own the source for the TNC-2.
That is held by (now) InfoMotion which is kind enough to continue to provide
TAPR with the updates and allows us to make them available ot the amateur
community without anyroyalities going back to him.

The DSP-93 monitor code was held in the dark -- this was becuase we wanted
only one monitor for the system.   One reason we have so many TNC-2 out in
the world is becuase the AX.25 code stayed stable...on the other hand we
still seem to be stuck at that speed and type system for the same types of
reasons.

Cheers - Greg, WD5IVD
Pres TAPR



From muphaus@cris.com  Wed Oct 09 20:59:32 1996
Received: from franklin.cris.com (franklin.cris.com [199.3.12.31]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id UAA27672 for <hfsig@tapr.org>; Wed, 9 Oct 1996 20:59:28 -0500 (CDT)
Received: from mariner.cris.com (mariner.cris.com [199.3.12.169])
	by franklin.cris.com (8.7.5/(96/09/19 2.55))
	id VAA07460; Wed, 9 Oct 1996 21:59:26 -0400 (EDT)
	[1-800-745-2747 The Concentric Network]
Errors-To: Muphaus@cris.com
Received: by mariner.cris.com (4.1) id AA01368; Wed, 9 Oct 96 21:59:26 EDT
From: muphaus@cris.com (Marv Uphaus)
Newsgroups: list.tapr.hfsig
To: hfsig@tapr.org
Subject: Re: [HFSIG:1631] Re: Why things are the way they are
Date: Wed, 09 Oct 1996 20:13:41 -0500
Organization: Not Organized
Reply-To: muphaus@cris.com
Message-Id: <F3EXyM82cm+Q085yn@cris.com>
References: <199610092000.PAA484744@gomer.wiscnet.net>
Lines: 55

On Wed, 9 Oct 1996 15:23:51 -0500 (CDT) "Rick Williams" <rwilliam@cesa4.k12.wi.us> wrote:

>Most comments about other peoples greed are a reflection of the very
>individual's own
>greed (as it is with most negative comments about others).

Woah, buddy...!!!

I cannot let your criticism of Phil go unanswered...!!!

First, you are generalizing here about whether someone of intelligence can
make a logical value judgement about another's motives without themselves
being guilty of the same sins...  I think they can...!!!  Otherwise the
publishing industry is out of business...!!!

I can also appreciate and understand Gwnn's comments about ham radio
manufacturers...  The profit motive has to be there for good products to
continue to be developed...  (A satisfied PacComm customer...)

Second, you obviously haven't been around digital ham radio for very long,
because if you had been, you'd realize that Phil Karn is one of the most
prolific and respected of the digital group...  Phil has authored MANY
things (NOS being the most widely known) and given them to the ham radio
community...  I'm sure Phil earns a nice salary with his company...  But
his efforts for digital ham radio have been herculean over the years...

I quote Ian Wade, G3NRW, in his book, "NOSintro"...

"Without Phil's [free] contribution, it's unlikely that the amateur packet
network would be anything like as advanced as it is today."

As far as the development of digital modes, the marketplace will surely
shake out all those that do not work for amateur radio...  Several are
dying as we communicate here on the Internet...  I remember a few years
back, Phil commented that the Internet has taken over the bulk of digital
communications for the amateur community...  He is certainly correct
there...!!!  Otherwise we'd be doing this on 20 Meters...

And while I'm on my soapbox, let me say this...!!!  If we want amateur
radio to flourish and grow, we will have to attract the technically
oriented kids of today...  Ham radio is NOT doing that...  All those young
people are heavily involved in computer projects, as we all were involved
in ham radio in our youth...

Keep up the good work, Phil...!!!  All us old geezers (41 years licensed
now) appreciate your efforts and we also appreciate your comments...  It's
good that you get us all rattled every once in a while...!!!  ;-)

Marv, K4BVG...

-----------------------------------------------------------
Even when the experts all agree, they may well be mistaken.
                                  --Bertrand Russell
PGP PUBLIC KEY posted at pgp.mit.edu
-----------------------------------------------------------

From LAITINEN@ESHOP.UOREGON.EDU Thu Oct 10 00:34:52 1996
Received: from ESHOP.UOREGON.EDU (eshop.uoregon.edu [128.223.94.14]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id AAA11345 for <hfsig@tapr.org>; Thu, 10 Oct 1996 00:34:50 -0500 (CDT)
Date:    Wed, 9 Oct 1996 22:36:03 -0700 (PDT)
From: LAITINEN@ESHOP.UOREGON.EDU
Message-Id: <961009223603.982@ESHOP.UOREGON.EDU>
Subject: SS et al..
To: hfsig@tapr.org, bcarver@magiclink.com
X-Vmsmail-To: SMTP%"hfsig@tapr.org"

Forwarded from Bill Carver, W7AAZ (ex-K6OLG)

Hey Larry....can you forward THIS as a comment?

After all is said and done, the ability of an amateur to interact with his
equipment on a hardware/software level is taken almost to the "impossible"
point in current equipment.

This total lack of visibility of the design makes it impossible for anyone
in our fraternity to improve any aspect of the situation. The lack of
visibility also appears to sometimes be used to "cover up" fairly serious
shortcomings and compromises that one would not expect from the glorious
advertising copy. 

Lets cut through all the BS: TAPR can guide an open effort to develop and
optimize hardware/software for an efficient, narrowband HF data mode. 
Lots of work has been done on point-to-point, high data rate
communications. I, for one, would like a mode suitable for
keyboard-keyboard, rountable, eavesdropping (ie, SWL) and autostart
functions. 

Bill, W7AAZ

From karn@qualcomm.com Thu Oct 10 04:31:54 1996
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id EAA17344 for <hfsig@tapr.org>; Thu, 10 Oct 1996 04:31:52 -0500 (CDT)
Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id CAA00427; Thu, 10 Oct 1996 02:31:21 -0700 (PDT)
Date: Thu, 10 Oct 1996 02:31:21 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199610100931.CAA00427@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <H0000292028d5122@MHS> (Robert.Glassey@nmp.nokia.com)
Subject: Re: [HFSIG:1622] Re: ARRL DCC and the old SS thread

>Are there any successfull high speed SS systems that operate for example
>on the aeronaughtical VHF band near an airport with a range of several
>miles, and several dozon similtainious users? My point is that existing
>applications have chosen their circumstances for a reason.

The military's JTIDS (Joint Tactical Information Distribution System)
is a spread spectrum system that operates in the 960-1215 MHz
TACAN/DME aeronautical navigation band on a non-interference basis. (I
know, that's UHF rather than VHF -- but it certainly *is* widely used
by civilian airliners for navigation.)

If I remember right, JTIDS notches out the 1030 and 1090 MHz slots in
its hopping sequence to protect secondary surveillance radars, but
they don't do anything special to protect the DMEs.

A quick Alta Vista search produced some Rockwell specs for some of
their JTIDS products. Data rates range from 28.8 to 238 kb/s.
Transmit powers up to 1000 W (!!) are available.

Perhaps Steve Bible can comment further on JTIDS.

--Phil

From karn@qualcomm.com Thu Oct 10 04:53:32 1996
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id EAA17984 for <hfsig@tapr.org>; Thu, 10 Oct 1996 04:53:30 -0500 (CDT)
Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id CAA00445; Thu, 10 Oct 1996 02:52:58 -0700 (PDT)
Date: Thu, 10 Oct 1996 02:52:58 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199610100952.CAA00445@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <25b9f7e0@mailb.harris.com> (RLANIER@mailb.harris.com)
Subject: Re: [HFSIG:1628] Re: ARRL DCC and the old SS thread

     The reason so many companies (and I assume TAPR as well) make software 
     proprietary is to protect their product. You have to look at it from 

That's what copyrights are for!

Believe it or not, I've done pretty well with commercial licensing of
NOS even though I put all of the source code out on the net. Enough to
help me pay off a good chunk of my mortgage. Sure, I've seen some
evidence of being ripped off, but there are enough honest companies
out there to make it worthwhile.

I admit, if NOS were my *sole* source of income I might feel somewhat
differently. In any event, I've been careful to avoid a very common
mistake: explicitly trying to make money off the ham market, as
opposed to doing it for fun and taking whatever comes later from
commercial spinoff sales as an unanticipated bonus.

I could name several who have made this mistake and bitterly regretted
it, but I don't think that's necessary. From the very beginning I knew
better than to even *think* of trying to charge hams for NOS or any
other software I do. As the saying goes, it'd be like trying to teach
a pig to sing. It wastes time and annoys the pig.

Phil

From k5yfw@www.kelly-afb.org Thu Oct 10 07:28:02 1996
Received: from www.kelly-afb.org (www.kelly-afb.org [204.214.204.10]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id HAA22163 for <hfsig@tapr.org>; Thu, 10 Oct 1996 07:28:00 -0500 (CDT)
Received: (from k5yfw@localhost) by www.kelly-afb.org (8.7.1/8.7.1) id HAA20981; Thu, 10 Oct 1996 07:28:55 -0500 (CDT)
From: Walt DuBose - K5YFW <k5yfw@www.kelly-afb.org>
Message-Id: <199610101228.HAA20981@www.kelly-afb.org>
Subject: Re: [HFSIG:1633] Re: Why things are the way they are
To: hfsig@tapr.org
Date: Thu, 10 Oct 1996 07:28:54 -0500 (CDT)
In-Reply-To: <F3EXyM82cm+Q085yn@cris.com> from "Marv Uphaus" at Oct 9, 96 09:09:50 pm
Reply-To: k5yfw@www.kelly-afb.org
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text

In Marv's message he writes:
> 
> On Wed, 9 Oct 1996 15:23:51 -0500 (CDT) "Rick Williams" <rwilliam@cesa4.k12.wi.us> wrote:
> 
> And while I'm on my soapbox, let me say this...!!!  If we want amateur
> radio to flourish and grow, we will have to attract the technically
> oriented kids of today...  Ham radio is NOT doing that...  All those young
> people are heavily involved in computer projects, as we all were involved
> in ham radio in our youth...

	Boy is that the truth...just sign me as:

	Director for RF Communications,
	Young Astronaut Technology Program
	North East Independent School District (NEISD)
	San Antonio, Texas

	Roosevelt High School, 
	TechMagnet High School for the NEISD

> 
> Keep up the good work, Phil...!!!  All us old geezers (41 years licensed
> now) appreciate your efforts and we also appreciate your comments...  It's
> good that you get us all rattled every once in a while...!!!  ;-)
> 
> Marv, K4BVG...

	Marv, you're just a _young-buck_...ya gotta be over 55 to qualify
	as an OG or OF...
> 
> 

	73 all,

	Walt/K5YFW, ex KN5YFW

=======================================================================
| The MicroSoft operating system didn't get as bad as it is overnight,|
| it has taken over 10 years of careful, calculated development.      |
=======================================================================
|				    |				      |
|                                   | The greatest dangers to liberty |
| Walt DuBose - K5YFW               | lurk in insidious encroachment  |
| E-Mail k5yfw@www.kelly-afb.org    | by men of zeal, well-meaning    |
| Business Telephone: (210)925-6081 | but without understanding.      | 
|     Home Telephone: (210)696-3196 | 				      |
|                                   |   - Justice Louis D. Brandeis   |
|     	                            |   			      |
=======================================================================

OBTW, if you've looked this far into my message, let me say that kids
like computer CW of HF more than voice...its an "HF chat room".

Please don't forget the JOTA, 19-20 Oct 96 on 80, 40?, 20, 15 & 10 meters.
See QST for frequencies but I think the 20 meter frequency is 14.290 MHz.
	-- k5yfw

From RLANIER@mailb.harris.com  Thu Oct 10 07:50:39 1996
Received: from sol.corp.Harris.COM (sol.corp.harris.com [137.237.25.4]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id HAA23053 for <hfsig@tapr.org>; Thu, 10 Oct 1996 07:50:37 -0500 (CDT)
Received: from mailb.harris.com by sol.corp.Harris.COM (8.6.12/Kurts Special version 2.0)
	id IAA22318; Thu, 10 Oct 1996 08:50:32 -0400
Received: from ccMail by mailb.harris.com
  (IMA Internet Exchange 1.04b) id 25cf0be0; Thu, 10 Oct 96 08:49:02 -0400
Mime-Version: 1.0
Date: Thu, 10 Oct 1996 08:49:28 -0400
Message-ID: <25cf0be0@mailb.harris.com>
From: RLANIER@mailb.harris.com (RLANIER)
Subject: Re: [HFSIG:1636] Re: ARRL DCC and the old SS thread
To: hfsig@tapr.org
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part

       
     >>The reason so many companies (and I assume TAPR as well) make software 
     >>proprietary is to protect their product. You have to look at it from 
     
>That's what copyrights are for!
     
Why should a company file for a copyright to protect their product????  
And copyrights expire!! Do you think Microsoft should file for a 
copyright for DOS? Look, my point here is that a COMPANY has the right 
to do what they want with their product. Just because we would like to 
know how Kenwood or Yaesu used DSP techniques in their new receivers, 
does not mean they have to show us how they did it!! Or to disclose 
their source code.

Now, if an individual wants to spend his/her free time on a project and 
then tell the rest of the amateur community about, great! But if they 
decide, hey, I've worked very hard on this and I want to see something 
in return, don't fault them for that either.

73s de
Tony

From Robert.Glassey@nmp.nokia.com Thu Oct 10 10:02:03 1996
Received: from noknic.nokia.com (noknic.nokia.com [131.228.6.10]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id KAA28658 for <hfsig@tapr.org>; Thu, 10 Oct 1996 10:02:00 -0500 (CDT)
From: Robert.Glassey@nmp.nokia.com
Received: from samail01.nmp.nokia.com (samail01.nmp.nokia.com [131.228.240.6]) by noknic.nokia.com (8.6.9/8.6.9) with ESMTP id RAA13837; Thu, 10 Oct 1996 17:00:38 +0200
Received: from  by samail01.nmp.nokia.com with SMTP
	(1.37.109.16/16.2) id AA095359656; Thu, 10 Oct 1996 18:00:56 +0300
X-Openmail-Hops: 2
Date: Thu, 10 Oct 96 12:33:43 +0100
Message-Id: <H0000292028b3749@MHS>
In-Reply-To: <199610100952.CAA00445@servo.qualcomm.com>
Subject: [HFSIG:1636] Re: ARRL DCC and the old SS thread
Sender: Robert.Glassey@nmp.nokia.com
To: hfsig@tapr.org, karn@qualcomm.com

>>The reason so many companies (and I assume TAPR as well) make software

>>proprietary is to protect their product. You have to look at it from 
> 
> That's what copyrights are for!
 
> Believe it or not, I've done pretty well with commercial licensing of
> NOS even though I put all of the source code out on the net. Enough to
> help me pay off a good chunk of my mortgage. Sure, I've seen some
> evidence of being ripped off, but there are enough honest companies
> out there to make it worthwhile.
> 
> I admit, if NOS were my *sole* source of income I might feel somewhat
> differently. In any event, I've been careful to avoid a very common
> mistake: explicitly trying to make money off the ham market, as
> opposed to doing it for fun and taking whatever comes later from
> commercial spinoff sales as an unanticipated bonus.

Yip, thats my position on BTL as well. I have no costs to cover, and
write it out of interest, and to help stimulate amateur digital comms by
making it free and widely available. And hey, any fame and fortune that
comes my way is greatfully accepted!

I intent to release a description of the DSP side of BTL shortly (as
soon as I finish it!) and quite probably selected portions of the source
code that is of specific interest (not all the extra rubbish to do the
UI and all the other support rubbish). But focus on the soundblaster,
filtering, and synchronisation algorithems etc. Just the essential guts
of the source code. Right now the code is not very modular is a bit of a
mess, and that's holding me back in further developemnt of BTL, so when
I get it sorted into modular units, I'll probably release specific
modules so folks can see how its done.

It serves two purposes, firstly it makes the source code understandable,
and usefull to anyone who wants to know how its done and perhaps wants
to implement their own modem for whatever purpose or mode or platform
etc, more for inspiration rather than drop-in directly useable code, and
secondly, anything I may get from BTL is still protected, since its all
the boring rubbish UI/support code that takes all the effort, and if
anyone want to rewrite that, the result would be pretty much their own
effort anyway, and anyone can do that. Users want a finished product.



Eluding back to the old SS thing..

I don't want to be seen as the spoil sport here, like most of you, I
want to see experimentation in any new mode, but there are potential
problems and they must be recognised and taken into account from the
outset otherwise we will end up with a poor system that will not be very
effective and may well cause interference to the point where the use of
SS is so limited that its value is completely eroded. If we just build a
DSSS system slap TCPIP over top, wait for the complaints and hope, we
will quickly be locked into a system almost as hopeless as HF packet on
80m, except causing a lot more interference and agrovation.

SS is a mode with new properties and new rules, and the adhoc principles
of sharing that allowed narrow band modes to coexist no longer work. The
rules of the two systems are inherently different and what works for one
does not nessesarily work for the other.

The absolutly worst thing we can do is blindly setup a system anywhere
and just expect no interference out of pure faith.

We must DESIGN the system to work, and that means selecting appropriate
bands, procesing gains, coding, antenna requirements, sensitivity
requirements, repeater/node distribution, and data rates that WILL work.
There were mistakes made with Packet, but the consequences weren't so
bad. A bad SS system could not only spell then end of SS as a usefull
mode, but also devalue ham radio to the point where perhaps it will
cease to exist. The stakes are much higher, this issue must be taken
seriously.

Once a bad system is running we will be locked into it an no amount of
goodwill on behalf of the SS or narrowband users will be able to resolve
the problems. By addressing these issues today we not only allay fears
and gain support, but we will be getting the very best SS system we can
get.

A while back I posted a set of guidelines intended as a first step along
these lines on SS-SIG, but it appears gun-blazing faith and blindness is
the prefered course of action. - This does nothing to instill confidance
amounst the critics.

Rob

From Robert.Glassey@nmp.nokia.com Thu Oct 10 10:12:30 1996
Received: from noknic.nokia.com (noknic.nokia.com [131.228.6.10]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id KAA29105 for <hfsig@tapr.org>; Thu, 10 Oct 1996 10:12:28 -0500 (CDT)
From: Robert.Glassey@nmp.nokia.com
Received: from samail01.nmp.nokia.com (samail01.nmp.nokia.com [131.228.240.6]) by noknic.nokia.com (8.6.9/8.6.9) with ESMTP id RAA15059; Thu, 10 Oct 1996 17:11:52 +0200
Received: from  by samail01.nmp.nokia.com with SMTP
	(1.37.109.16/16.2) id AA101090332; Thu, 10 Oct 1996 18:12:13 +0300
X-Openmail-Hops: 2
Date: Thu, 10 Oct 96 12:41:30 +0100
Message-Id: <H0000292028b3754@MHS>
In-Reply-To: <199610100931.CAA00427@servo.qualcomm.com>
Subject: [HFSIG:1635] Re: ARRL DCC and the old SS thread
Sender: Robert.Glassey@nmp.nokia.com
To: hfsig@tapr.org, karn@qualcomm.com

> The military's JTIDS (Joint Tactical Information Distribution System)
> is a spread spectrum system that operates in the 960-1215 MHz
> TACAN/DME aeronautical navigation band on a non-interference basis. (I
> know, that's UHF rather than VHF -- but it certainly *is* widely used
> by civilian airliners for navigation.)
> 
> If I remember right, JTIDS notches out the 1030 and 1090 MHz slots in
> its hopping sequence to protect secondary surveillance radars, but
> they don't do anything special to protect the DMEs.
> 
> A quick Alta Vista search produced some Rockwell specs for some of
> their JTIDS products. Data rates range from 28.8 to 238 kb/s.
> Transmit powers up to 1000 W (!!) are available.

Now here's an example of a system thats obviously been well designed.
Navagation is fairly interference tollerant, 245 MHz -> 238kb/s is a lot
of processing gain, navagation ranges are a lot further than high speed
data links, the SS transmitters will be a long way from any airborne
navagation receiver, and of course they notch out sensitive bands.
Sounds like it should work, and it obviously does.

So lets apply so good design principles to the amateur application.

Rob

From Robert.Glassey@nmp.nokia.com Thu Oct 10 10:42:06 1996
Received: from noknic.nokia.com (noknic.nokia.com [131.228.6.10]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id KAA00752 for <hfsig@tapr.org>; Thu, 10 Oct 1996 10:42:03 -0500 (CDT)
From: Robert.Glassey@nmp.nokia.com
Received: from samail01.nmp.nokia.com (samail01.nmp.nokia.com [131.228.240.6]) by noknic.nokia.com (8.6.9/8.6.9) with ESMTP id RAA18344 for <hfsig@tapr.org>; Thu, 10 Oct 1996 17:41:30 +0200
Received: from  by samail01.nmp.nokia.com with SMTP
	(1.37.109.16/16.2) id AA119902110; Thu, 10 Oct 1996 18:41:51 +0300
X-Openmail-Hops: 2
Date: Thu, 10 Oct 96 13:23:38 +0100
Message-Id: <H0000292028b5f11@MHS>
In-Reply-To: <961009223603.982@ESHOP.UOREGON.EDU>
Subject: Higly robust HF modes
Sender: Robert.Glassey@nmp.nokia.com
To: hfsig@tapr.org

> Lets cut through all the BS: TAPR can guide an open effort to develop
> and optimize hardware/software for an efficient, narrowband HF data
> mode. Lots of work has been done on point-to-point, high data rate
> communications. I, for one, would like a mode suitable for
> keyboard-keyboard, rountable, eavesdropping (ie, SWL) and autostart
> functions. 
> 
> Bill, W7AAZ

You are not alone :-)

There are a number of people interested in this application on HFSIG. 

BPSK and MFSK have been suggested, I'd like to be able to spend more
time on it myself. Replacing RTTY with a more robust mode, but still
allowing the free form QSO's for contesting, roundtables etc is one
application, as is communicating with very poor signal to noise ratios,
such as QRP DX, emergancy comms from a handheld HF rig and simple low

wire antenna, and the LF band (73kHz in the UK).

I wonder if there has been any recent progress on the BPSK front?

Cheers,

Rob

From RLANIER@mailb.harris.com  Thu Oct 10 13:32:37 1996
Received: from sol.corp.Harris.COM (sol.corp.harris.com [137.237.25.4]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id NAA07831 for <hfsig@tapr.org>; Thu, 10 Oct 1996 13:32:36 -0500 (CDT)
Received: from mailb.harris.com by sol.corp.Harris.COM (8.6.12/Kurts Special version 2.0)
	id OAA19822; Thu, 10 Oct 1996 14:32:30 -0400
Received: from ccMail by mailb.harris.com
  (IMA Internet Exchange 1.04b) id 25d40e50; Thu, 10 Oct 96 14:31:01 -0400
Mime-Version: 1.0
Date: Thu, 10 Oct 1996 14:31:17 -0400
Message-ID: <25d40e50@mailb.harris.com>
From: RLANIER@mailb.harris.com (RLANIER)
Subject: Re: [HFSIG:1639] Re: ARRL DCC and the old SS thread
To: hfsig@tapr.org
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part

     
     
Eluding back to the old SS thing..
     
     
>SS is a mode with new properties and new rules, and the adhoc principles 
>of sharing that allowed narrow band modes to coexist no longer work. The 
>rules of the two systems are inherently different and what works for one 
>does not nessesarily work for the other.
     
>The absolutly worst thing we can do is blindly setup a system anywhere 
>and just expect no interference out of pure faith.
     
>We must DESIGN the system to work, and that means selecting appropriate 
>bands, procesing gains, coding, antenna requirements, sensitivity 
>requirements, repeater/node distribution, and data rates that WILL 
>work. There were mistakes made with Packet, but the consequences 
>weren't so bad. A bad SS system could not only spell then end of SS as 
>a usefull mode, but also devalue ham radio to the point where perhaps 
>it will cease to exist. The stakes are much higher, this issue must be 
>taken seriously.
     
     You're absolutely right, Rob. SS definitely has to be carefully 
     thought out in order to work correctly. I don't think one single bad 
     design will cause amateur radio to cease to exist. It would definitely 
     give the non-SS crowd some fuel for their fire, though.
     
     Some have argued that using 220MHz and above is the way to go. The 
     only benefit I can see for this is having a wider spreading band. One 
     important issue is the use of error correction, which will become very 
     important in high-speed data transmission. Another is data conversion, 
     but this is becoming a moot issue with the new ADCs and DACs coming 
     out. I for one will keep slugging away at it and yes, I will share 
     what I come up with!
     
>A while back I posted a set of guidelines intended as a first step along 
>these lines on SS-SIG, but it appears gun-blazing faith and blindness is 
>the prefered course of action. - This does nothing to instill confidance 
>amounst the critics.

>Rob
     
     I think the reason for this is there is still widespread discussion 
     about the merits of SS in general - interference being the biggest 
     concern. Some of us will have to start discussing certain aspects of 
     SS and go from there.
     
     
     73s de
     Tony,  KE4ATO



       

From forrerj@peak.org  Thu Oct 10 16:39:14 1996
Received: from PEAK.ORG (root@PEAK.ORG [198.68.22.17]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id QAA13669 for <hfsig@tapr.org>; Thu, 10 Oct 1996 16:39:12 -0500 (CDT)
Received: from p00.t0.monrotel.com (p00.t0.monrotel.com [198.68.25.33]) by PEAK.ORG (8.6.13/8.6.7) with SMTP id OAA21906 for <hfsig@tapr.org>; Thu, 10 Oct 1996 14:39:20 -0700
Message-Id: <199610102139.OAA21906@PEAK.ORG>
X-Sender: forrerj@peak.org (Unverified)
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 10 Oct 1996 14:37:19 -0800
To: hfsig@tapr.org
From: forrerj@peak.org (Johan Forrer)
Subject: Re: [HFSIG:1641] Higly robust HF modes

Hi Rob,


Congratulations on BTL! I have played with it and you have done a nice job.
Besides the fact that it works better than a lot of TNC's on RTTY - you seem
to have mastered the art of dealing with all those Sound-Blaster
compatibility issues. 

There recently was another announcement by Brian Cauchi, 9H1JS, of his
program called FTV. It incorporates SSTV, WEFAX, and RTTY - all with a
Soundblaster card. Looks like a nice job, but doesn't run on my Soundblaster
which is a genuine Creative Labs, SB16. So, that was a bit of a dissapointment. 
See http://www.geocities.com/SiliconValley/2504/ for a link to the FTV software.

>BPSK and MFSK have been suggested, I'd like to be able to spend more
>time on it myself. Replacing RTTY with a more robust mode, but still
>allowing the free form QSO's for contesting, roundtables etc is one
>application, as is communicating with very poor signal to noise ratios,
>such as QRP DX, emergancy comms from a handheld HF rig and simple low
>wire antenna, and the LF band (73kHz in the UK).
>
>I wonder if there has been any recent progress on the BPSK front?
>

Yes, as a matter of fact. There is a small group for G and PA0 hams that now
uses a slowspeed BPSK (31.5 baud). Peter Martinez, G3PLX, devised a novel
coding scheme for this keyboard-keyboard mode that may well replace regular
RTTY as we know it. It also has the possibility to be implemented using the
Soundblaster approach as for BTL. Here is how its works:

        "The idea is very like morse-code, which has the interesting
property that
        although it's an asynchronous code, it can never stay out of
character-sync 
        on single bit-errors, since the 000 letterspace pattern never occurs 
        within a codeword. Once I spotted that, the variable-length code almost
        devised itself:

        1) Codewords are separated from each other by two consecutive zeros.
        2) No codeword contains 2 or more embedded consecutive zeros.

        It follows from this that all codewords start and end with 1.

        I collected about 1M of assorted (english) ASCII(128) text files and
        sorted them into descending frequency order, then assigned them to a
list
        of all binary codewords meeting the above two criteria, in ascending
order
        of length. The result is the alphabet at the end of this message,
which is
        in ASCII order. The longest code is 10 bits. I transmit LSB first. The
        code shown in the alphabet has the 00 gap added on the end (the msb
end) and
        then a dummy '1' which marks the length and is not transmitted. The
codeword
        for the letter 'a' is, for example, 1101, transmitted left to right.
        idle-line is a continuous 00000 stream, and of course with BPSK I choose
        this to be represented by continuous phase-reversals so that the distant
        receiver can recover bitclock. There are never more consecutive 1's than
        the maximum-length codeword, so bitstuffing isn't needed."

        (Personal Communication: Peter Martinez, G3PLX)
  
Neat - is'nt it? I'll ask for Peter's consent to post the code alphabet and
a pseudo coder/decoder and get more folks involved. 

--Johan

From karn@qualcomm.com Thu Oct 10 19:05:27 1996
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id TAA19088 for <hfsig@tapr.org>; Thu, 10 Oct 1996 19:05:23 -0500 (CDT)
Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id RAA01942; Thu, 10 Oct 1996 17:04:51 -0700 (PDT)
Date: Thu, 10 Oct 1996 17:04:51 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199610110004.RAA01942@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <H0000292028d5122@MHS> (Robert.Glassey@nmp.nokia.com)
Subject: Re: [HFSIG:1622] Re: ARRL DCC and the old SS thread

>You don't get something for nothing, SS does not work by magic, it must
>still obey the laws of physics. It's a question of whether what you use
>will be missed.

I actually quite agree with this. SS systems have to be engineered
just like any other communication system. Some will work and some
won't, and some will interfere just as some won't. It all depends.

Where I think we part company is in what the rules should say. I
advocate the least restrictive FCC rules possible on SS, with the
amateur communitity working out its own technical standards and
procedures to resolve intra-service QRM. It is simply not realistic or
fair to maintain a flat ban on SS on so many amateur bands because of
the possibility (not certainty) of QRM. Again, we're not a "safety of
life" service, we're an experimental and educational service. We need
rules that recognize this, or we're going to fade completely into
irrelevance.

By the way, you sound much like Andrew Viterbi in an informal paper he
wrote for IEEE Communications Magazine back in April 1985. Apparently
he too was perturbed at the time by the overzealousness of some SS
proponents. But he probably regretted ever writing that paper when his
own words were quoted back to him in the early days of Qualcomm CDMA
by those who thought that the relative merits of CDMA could be debated
by analogy and appeals to authority instead of being resolved by
quantitative analyses and actual experiments.

Phil

From RLANIER@mailb.harris.com  Fri Oct 11 07:50:24 1996
Received: from sol.corp.Harris.COM (sol.corp.harris.com [137.237.25.4]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id HAA14687 for <hfsig@tapr.org>; Fri, 11 Oct 1996 07:50:22 -0500 (CDT)
Received: from mailb.harris.com by sol.corp.Harris.COM (8.6.12/Kurts Special version 2.0)
	id IAA14357; Fri, 11 Oct 1996 08:50:16 -0400
Received: from ccMail by mailb.harris.com
  (IMA Internet Exchange 1.04b) id 25e42300; Fri, 11 Oct 96 08:48:48 -0400
Mime-Version: 1.0
Date: Fri, 11 Oct 1996 08:49:54 -0400
Message-ID: <25e42300@mailb.harris.com>
From: RLANIER@mailb.harris.com (RLANIER)
Subject: Re: [HFSIG:1644] Re: ARRL DCC and the old SS thread
To: hfsig@tapr.org
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part

     
>Where I think we part company is in what the rules should say. I 
>advocate the least restrictive FCC rules possible on SS, with the 
>amateur communitity working out its own technical standards and 
>procedures to resolve intra-service QRM. It is simply not realistic or 
>fair to maintain a flat ban on SS on so many amateur bands because of 
>the possibility (not certainty) of QRM. Again, we're not a "safety of 
>life" service, we're an experimental and educational service. We need 
>rules that recognize this, or we're going to fade completely into 
>irrelevance.
     
>Phil
     
     I couldn't agree more! Whats really worrysome is the blind rage some 
     amateurs have when it comes to SS. I can parallel it to the current 
     state of our federal government, but that is another subject ...
     
     I'm not going to argue the merits of SS anymore. I KNOW its a good 
     modulation method. So I will proceed with the ideas I have. And yes, I 
     will share them with the rest of the amateur community  ;)
     
     73s de
     Tony,  KE4ATO

From rkb1@rfpo1.rfc.comm.harris.com Fri Oct 11 08:09:09 1996
Received: from adm01.rfc.comm.harris.com (adm01.rfc.comm.harris.com [147.177.128.2]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id IAA15259 for <hfsig@tapr.org>; Fri, 11 Oct 1996 08:09:04 -0500 (CDT)
Received: from smtpgate.rfc.comm.harris.com ([147.177.5.94]) by adm01.rfc.comm.harris.com (8.6.12/8.6.9) with SMTP id JAA25398 for <hfsig@tapr.org>; Fri, 11 Oct 1996 09:08:59 -0400
Received: by smtpgate.rfc.comm.harris.com with Microsoft Mail
	id <325E45D8@smtpgate.rfc.comm.harris.com>; Fri, 11 Oct 96 09:04:24 DST
From: "Breon, Roy K" <rkb1@rfpo1.rfc.comm.harris.com>
To: "'smtp:hfsig@tapr.org'" <hfsig@tapr.org>
Subject: Re: ARRL DCC and the old SS thread
Date: Fri, 11 Oct 96 09:09:00 DST
Message-ID: <325E45D8@smtpgate.rfc.comm.harris.com>
Encoding: 62 TEXT
X-Mailer: Microsoft Mail V3.0


There have been several comments on this list recently regarding proprietary 
waveforms and/or proprietary software/firmware.  I just thought that I'd add 
my $.02 from a manufacturer's perspective.

Harris Corporation is the inventor of the high speed HF modem technology 
that was later implemented into MIL-STD-188-110 and some of its appendices, 
As Walt DuBose stated in an earlier post, these specifications relate to 
speeds up to 4800 BPS in a 3kHz HF channel.  The specifications define the 
on -the-air waveform characteristics such that many people could generate 
and receive the waveform.  We released that information on the waveform 
design and do not retain any patent rights in this area.  This was done in 
the interest of promoting advanced used of HF radio and to encourage others 
to use such modems.  Since then several manufacturers introduced 
MIL-STD-188-110 modems with various degrees of compliance to the 
specification.  The techniques and source code that we use to generate the 
waveform is not covered in the specification and is not released in any of 
our instruction manuals either.  It is copyrighted and also retained as a 
trade secret.  In fact, the details have changed over the years as newer 
hardware technology became available.  The earliest versions of the RF-5254 
HF Modem used bit slice technology.  Newer versions such as the RF-5710 HF 
Modem use DSP technology.

The receiver portion, the DEM portion of the MODEM, is where the real 
expertise lies.  The MIL spec does not really dwell on the demodulation 
portion.  You might expect this since the spec is only concerned with 
interoperability and that basically involves the on-the-air waveform.  We do 
have several patents related to how the receiver portion of  our modems is 
implemented.  Harris provides some pretty good features such as filtering 
out jamming (read interfering) waveforms, adaptive channel equalization, 
data directed equalization, and soft decision decoding, etc.  These features 
are not described in the MIL spec but are used to wring out as much 
information as possible from the standardized transmitted waveform. 
 However, others could demodulate the waveforms using other techniques 
without infringing on our patents.  The demodulator just wouldn't be as good 
and wouldn't perform with as good a BER for a given Eb/No and other channel 
conditions.  In addition to the patent and copyright protection, the exact 
source code is retained as proprietary information.

Speaking of interfering signals -- noise is a form of interference.  Using 
our modem, we can actually receive error free data with received signals 
having negative signal to noise ratios.  In other words, the signal is below 
the noise.  This has obvious benefits for the user.

One could consider some of these advanced waveforms as a form of spread 
spectrum.  The serial tone waveforms described by the Mil spec use a single 
tone modulated in a very high and complex way.  For slow speed waveforms 
such as 75 bps which could be transmitted in a fairly narrow bandwidth, we 
continue to use the full 3 kHz channel thus "spreading" the waveform.

Development of such technology is not inexpensive nor is the cost to produce 
such a product.  In order for Harris and other companies to protect their 
investment it is necessary to keep much of the implementation technology 
 proprietary.  As you all know, unlike duplicating hardware, firmware that 
costs hundreds of thousands of dollars to create can be easily duplicated 
for a very low cost.  Therefore, if development in the field is to continue, 
it is mandatory that patents, copyrights, and trade secrets be used.

Roy K. Breon
Manager, Marketing
Harris Corporation
RF Communications Division

From forrerj@peak.org  Fri Oct 11 12:17:20 1996
Received: from PEAK.ORG (root@PEAK.ORG [198.68.22.17]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id MAA23019 for <hfsig@tapr.org>; Fri, 11 Oct 1996 12:17:19 -0500 (CDT)
Received: from p02.t0.monrotel.com (p04.t0.monrotel.com [198.68.25.37]) by PEAK.ORG (8.6.13/8.6.7) with SMTP id KAA17821 for <hfsig@tapr.org>; Fri, 11 Oct 1996 10:17:27 -0700
Message-Id: <199610111717.KAA17821@PEAK.ORG>
X-Sender: forrerj@peak.org
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 11 Oct 1996 10:15:28 -0800
To: hfsig@tapr.org
From: forrerj@peak.org (Johan Forrer)
Subject: Re: [HFSIG:1646] Re: ARRL DCC and the old SS thread

Roy,


I really enjoyed and appreciated your posting regarding Harris' products.

........ (lines deleted)....

>Development of such technology is not inexpensive nor is the cost to produce 
>such a product.  In order for Harris and other companies to protect their 
>investment it is necessary to keep much of the implementation technology 
> proprietary.  As you all know, unlike duplicating hardware, firmware that 
>costs hundreds of thousands of dollars to create can be easily duplicated 
>for a very low cost.  Therefore, if development in the field is to continue, 
>it is mandatory that patents, copyrights, and trade secrets be used.
>
>Roy K. Breon
>Manager, Marketing
>Harris Corporation
>RF Communications Division
>

I have no problem with this philosophy. There are those ways and means for
maufacturers to protect their technolgy. Regarding amateur radio
experimentation on the other hand; I have personally tried to make the point
at all HFSIG meetings that we are not asking, nor expecting proprietory
trade secrets or software from anyone (it would be nice, but naive to expect
that :-). 

The troubling issue, in my mind, is (was) the recent emergence of
proprietory protocols that excludes all amateurs from experimenting with
basic principles. This is contrary to the spirit of the amateur radio hobby.
If one is into manufacturing or into some commercial venture, you should
expect to follow the rules, pay the price and reap the rewards, thats
another matter - commercial radio. Fortunately, Part 97 now outlaws such
unpublished protocols for use on the amateur radio bands. So we may see
things change for the future.

We as amateur experimentors, can, and must continue to participate in the
development of future HF digital communication systems. I believe that this
kind of grassroots effort is possible from the talents and synergy from a
group like HFSIG. It will, however, only be a small handful that will
actually do the effort to translate casual discussion into real working
models. I am not sure that these folks pose much, if any, threat to
manufacturers and business.

My 2-cents worth.

--Johan
 

  

From chbrain@dircon.co.uk Fri Oct 11 13:01:10 1996
Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id NAA24350 for <hfsig@tapr.org>; Fri, 11 Oct 1996 13:01:07 -0500 (CDT)
Received: by felix.dircon.co.uk id AA23033
  (5.67b/IDA-1.5 for <hfsig@tapr.org>); Fri, 11 Oct 1996 18:54:16 +0100
Received: from gw2-151.pool.dircon.co.uk(194.112.35.151) by amnesiac via smap (V1.3)
	id sma023003; Fri Oct 11 18:53:40 1996
Message-Id: <1.5.4.32.19961011165015.00678a00@popmail.dircon.co.uk>
X-Sender: chbrain@popmail.dircon.co.uk
X-Mailer: Windows Eudora Light Version 1.5.4 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 11 Oct 1996 17:50:15 +0100
To: hfsig@tapr.org
From: Charles Brain <chbrain@dircon.co.uk>
Subject: Re: [HFSIG:1646] Re: ARRL DCC and the old SS thread

>have several patents related to how the receiver portion of  our modems is 
>implemented.  Harris provides some pretty good features such as filtering 
>out jamming (read interfering) waveforms, adaptive channel equalization, 
>data directed equalization, and soft decision decoding, etc.  These features 

Yes as Fredricks found out to their cost!

>
>Roy K. Breon
>Manager, Marketing
>Harris Corporation
>RF Communications Division
>
>
>

Charles Brain.

From karn@unix.ka9q.ampr.org Mon Oct 14 04:33:24 1996
Received: from unix.ka9q.ampr.org (karn@unix.ka9q.ampr.org [129.46.90.35]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id EAA28989 for <hfsig@tapr.org>; Mon, 14 Oct 1996 04:33:21 -0500 (CDT)
Received: (from karn@localhost) by unix.ka9q.ampr.org (8.7.4/8.7.3) id CAA14733; Mon, 14 Oct 1996 02:32:56 -0700 (PDT)
Date: Mon, 14 Oct 1996 02:32:56 -0700 (PDT)
Message-Id: <199610140932.CAA14733@unix.ka9q.ampr.org>
From: Phil Karn <karn@unix.ka9q.ampr.org>
To: gwyn@paccomm.com
CC: hfsig@tapr.org
Reply-To: karn@qualcomm.com
In-reply-to: <01BBB5E1.791C7DC0@gwyn.paccomm.com> (message from Gwyn Reedy on
	Wed, 9 Oct 1996 12:01:41 -0500 (CDT))
Subject: Re: [HFSIG:1630] Why things are the way they are

Gwyn,

Some comments on your reply to my message of last week.

I certainly don't take you, Paccomm or any other manufacturer to task
for charging for the hardware products you sell.  Companies like
Paccomm provide a necessary service to the amateur community. And
since you take a financial risk whenever you bring a product to
market, it's entirely reasonable to make a profit in exchange for that
risk. My problem is most definitely NOT with the fact that commercial
amateur products cost money.

My problem *is* that they come so often as black boxes. Sure, they
generally work as advertised. But they generally fail to perform a
more important function, which is to give the amateur who buys them
the opportunity to learn as much as he wants about how the device
functions.

There may or may not be a schematic. But there is rarely a source code
listing, and with so much of the functionality of today's products in
software a schematic doesn't say very much.

I understand that the TAPR TNC code was not yours (or even TAPR's) to
publish. That was certainly the perogative of the original author. I
am only pointing out the drawbacks of that position as seen from the
larger perspective of what the amateur service is supposed to be all
about -- self-motivated, hands-on, technical education and training.

I guess it is just a sign of the times that most hams don't seem to
care what's behind the knobs (or "underneath the keyboard", to be more
current.)

But I do care very much. The non-ham world has resources to develop
new communications technology that we couldn't possibly match (even if
we weren't already 20 years behind), cell phones and other commercial
systems have made ham radio all but irrelevant for emergency
communications, and the Internet has made ham radio essentially
irrelevant in the "international good will" category.

So I see very clearly the fact that technical education is the only
aspect of ham radio that still has any relevance, and black boxes
don't exactly promote this particular goal.

Phil

From Robert.Glassey@nmp.nokia.com Tue Oct 15 12:54:07 1996
Received: from noknic.nokia.com (noknic.nokia.com [131.228.6.10]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id MAA05131 for <hfsig@tapr.org>; Tue, 15 Oct 1996 12:54:04 -0500 (CDT)
From: Robert.Glassey@nmp.nokia.com
Received: from samail01.nmp.nokia.com (samail01.nmp.nokia.com [131.228.240.6]) by noknic.nokia.com (8.6.9/8.6.9) with ESMTP id TAA04138 for <hfsig@tapr.org>; Tue, 15 Oct 1996 19:53:06 +0200
Received: from  by samail01.nmp.nokia.com with SMTP
	(1.37.109.16/16.2) id AA249091993; Tue, 15 Oct 1996 20:53:13 +0300
X-Openmail-Hops: 2
Date: Tue, 15 Oct 96 18:45:15 +0100
Message-Id: <H0000292029241b2@MHS>
In-Reply-To: <25d40e50@mailb.harris.com>
Subject: SS thread
Sender: Robert.Glassey@nmp.nokia.com
To: hfsig@tapr.org

> You're absolutely right, Rob. SS definitely has to be carefully 
> thought out in order to work correctly. I don't think one single bad 
> design will cause amateur radio to cease to exist. It would definitely

> give the non-SS crowd some fuel for their fire, though.
>   
> Some have argued that using 220MHz and above is the way to go. The 
> only benefit I can see for this is having a wider spreading band. One 
> important issue is the use of error correction, which will become very

> important in high-speed data transmission. Another is data conversion,

> but this is becoming a moot issue with the new ADCs and DACs coming 
> out. I for one will keep slugging away at it and yes, I will share 
> what I come up with!

> I think the reason for this is there is still widespread discussion 
> about the merits of SS in general - interference being the biggest 
> concern. Some of us will have to start discussing certain aspects of 
> SS and go from there.

I agree. But I believe the two are strongly related. There is no doubt a
poor system can cause interference. Many see the claimed advantages
weighed against this interfernce potential and don't like the way the
balance swings, the see too few benifits for too few people and a great
risk to them personally. The only way to convince people that
experimenting in SS is worthwhile (which I believe it is) is to reassure
them that there will be no interference. And I dont mean 'because I say
so' or 'other systems don't have problems', that doesn't wash. What we
need to a set of guidelines that outline the bare bones of a system (or
systems) that on paper will not cause interference.

Sure, the practicalities may work out in our favor, but thats no
gaurantee. We must start off small, and err on the side of caution to
convince people we are serious about non-interference. Publishing
guidlines and arguments why there will be no interference if these
guidelines are followed, as well as solutions or even work being done to
find solutions to the problems will go some way to convincing people
that we are not out to take away their enjoyment of the bands, and do
take non-interference seriously.

When we understand more about what makes a system work in an amateur
enviroment and have solved the various problems it presents then we can
perhaps move on to other bands, greater data rates, and more intensive
sharing.

I believe a lot can be acheived with quite restricted systems that non
SS people can feel comfortable with.

Paricularly at UHF/microwave frequencies which are ideally suited to low
interference. These frequencies have many advantages:

- High processing gains and thus low PSD's and high tollerance to
  uncontrolled transmitters

- Directional antennas which in turn allows lower power, and even
  less in unintended directions

- Low band occupancy, ie the chances are that your neighbour won't be
  using the band. - unless they're using SS to, where normal near-far
  control will do the trick. (central coordination, band splitting
  (TX/RX), power control)

- Interference tollerant encumbant modes, ie FM

- Encumbant users typically use directional antennas further reducing
  interference potential

- Other users also use low power, reduceing interference to a SS system

- Propagation is natuarly limited, reducing interfernce potential and
  the number of possible SS/narrow band stations that could cause
  interference to either system.

- They're politically easier, since it wont effect the bulk of the
  amateur population. It's easier to coordinate interference
  reduction efforts with a few local users than with many users on a
  national or global scale.

- Competitive, high data rates are possible for the same processing
  gain, although more gain will probably be needed to counter the
  effects of increasing power to acheive the same Eb/No. Still an
  overall gain.

These are the ideas that need to be thrashed out. General discussion
serves only to raise awareness of problems unless the issue of
interference is effectivly dealt with at the same time.

Rob

From Robert.Glassey@nmp.nokia.com Tue Oct 15 13:08:29 1996
Received: from noknic.nokia.com (noknic.nokia.com [131.228.6.10]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id NAA05647 for <hfsig@tapr.org>; Tue, 15 Oct 1996 13:08:26 -0500 (CDT)
From: Robert.Glassey@nmp.nokia.com
Received: from samail01.nmp.nokia.com (samail01.nmp.nokia.com [131.228.240.6]) by noknic.nokia.com (8.6.9/8.6.9) with ESMTP id UAA05728; Tue, 15 Oct 1996 20:07:54 +0200
Received: from  by samail01.nmp.nokia.com with SMTP
	(1.37.109.16/16.2) id AA254132884; Tue, 15 Oct 1996 21:08:04 +0300
X-Openmail-Hops: 2
Date: Tue, 15 Oct 96 19:04:44 +0100
Message-Id: <H0000292029241bd@MHS>
In-Reply-To: <199610102139.OAA21906@PEAK.ORG>
Subject: [HFSIG:1643] Re: Higly robust HF modes
Sender: Robert.Glassey@nmp.nokia.com
To: forrerj@peak.org, hfsig@tapr.org

> See http://www.geocities.com/SiliconValley/2504/ for a link to the FTV

> software.

I've downloaded it. I'll give it a try.

G3PLX wrote:

> "The idea is very like morse-code, which has the interesting property
> that although it's an asynchronous code, it can never stay out of
> character-sync on single bit-errors, since the 000 letterspace pattern
> never occurs within a codeword. Once I spotted that, the variable-
> length code almost devised itself:

I like it. Does it also have the property that it works just as well if
the polarity is reversed, ie you can detect that polarity is reversed,
flip it and carry on decoding OK. Or does it require a differential BPSK
channel, ie change/no-change where polatity is always known?

> Neat - is'nt it? I'll ask for Peter's consent to post the code
> alphabet and a pseudo coder/decoder and get more folks involved. 

Yes please.

Thanks,

Rob

From lbush@eramp.net Tue Oct 15 14:52:03 1996
Received: from www (www.eramp.net [206.149.42.1]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id OAA09254 for <hfsig@tapr.org>; Tue, 15 Oct 1996 14:52:01 -0500 (CDT)
Received: from lbush@eramp.net.www by www (SMI-8.6/SMI-SVR4)
	id OAA29070; Tue, 15 Oct 1996 14:51:14 -0500
Message-Id: <2.2.32.19961015195109.006f93b0@eramp.net>
X-Sender: lbush@eramp.net
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 15 Oct 1996 14:51:09 -0500
To: hfsig@tapr.org
From: Larry Bush <lbush@eramp.net>
Subject: Ham Radio Clip Art

Does anyone know of a source of Ham Radio Clip Art?
I Want to make up my own QSL and calling Cards.

73
---------------
Larry Bush, W5NCD
359 Arrowhead Point
Waco, TX 76712
Ph. 817-848-5155

From RLANIER@mailb.harris.com  Tue Oct 15 15:00:08 1996
Received: from sol.corp.Harris.COM (sol.corp.harris.com [137.237.25.4]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id PAA09391 for <hfsig@tapr.org>; Tue, 15 Oct 1996 15:00:05 -0500 (CDT)
Received: from mailb.harris.com by sol.corp.Harris.COM (8.6.12/Kurts Special version 2.0)
	id PAA00608; Tue, 15 Oct 1996 15:59:54 -0400
Received: from ccMail by mailb.harris.com
  (IMA Internet Exchange 1.04b) id 263eccd0; Tue, 15 Oct 96 15:58:05 -0400
Mime-Version: 1.0
Date: Tue, 15 Oct 1996 15:55:13 -0400
Message-ID: <263eccd0@mailb.harris.com>
From: RLANIER@mailb.harris.com (RLANIER)
Subject: Re: [HFSIG:1650] SS thread
To: hfsig@tapr.org
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part

>so' or 'other systems don't have problems', that doesn't wash. What we 
>need to a set of guidelines that outline the bare bones of a system (or 
>systems) that on paper will not cause interference.
     
     Why not follow the existing amateur rules that all ready exist? We 
     shouldn't cause harmfull interference, period. Neither should someone 
     running a SSB system at 100 watts. If we follow good design practices 
     and workmanship, which all homebrewers should, then we shouldn't have 
     any problems. 
     
>Publishing guidlines and arguments why there will be no interference if 
>these guidelines are followed, as well as solutions or even work being 
>done to find solutions to the problems will go some way to convincing 
>people that we are not out to take away their enjoyment of the bands, 
>and do take non-interference seriously.
     
     I think what would work even better is if a club or group would 
     conduct tests of SS and "regular" systems, side-by-side, and listen 
     for interference. What better way than to demonstrate it? 
     
>When we understand more about what makes a system work in an amateur 
>enviroment and have solved the various problems it presents then we can 
>perhaps move on to other bands, greater data rates, and more intensive 
>sharing.

     Of course. You always want to start small, test your idea and go from 
     there. Its a "bottom-up" design approach.
     
     My approach is to use a chip set, design the system around that, use 
     low output power (I believe the PRISM chip set outputs 250 mW) and go 
     from there. Once that works, design a more "fancier" system, using 
     frequency hopping, hybrid SS and faster data rates.
     
     
     
     73s de
     Tony

From karn@qualcomm.com Tue Oct 15 17:13:53 1996
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id RAA14666 for <hfsig@tapr.org>; Tue, 15 Oct 1996 17:13:52 -0500 (CDT)
Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id PAA12455; Tue, 15 Oct 1996 15:12:37 -0700 (PDT)
Date: Tue, 15 Oct 1996 15:12:37 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199610152212.PAA12455@servo.qualcomm.com>
To: RLANIER@mailb.harris.com (RLANIER)
Cc: hfsig@tapr.org
In-reply-to: <25cf0be0@mailb.harris.com> (RLANIER@mailb.harris.com)
Subject: Re: [HFSIG:1638] Re: ARRL DCC and the old SS thread

>Why should a company file for a copyright to protect their product????  
>And copyrights expire!! Do you think Microsoft should file for a 
>copyright for DOS? Look, my point here is that a COMPANY has the right 

Every copy of DOS I've ever seen has a Microsoft copyright notice. And
current US law says that copyrights are automatic; you don't have to
file for one unless you want to sue for infringement.

Copyrights have a term of the life of the author plus 50 years,
or for "works for hire", 100 years from the date of creation or 75
years from first publication, whichever comes first.

These terms are so long, especially for computer software, as to be
essentially infinite. (Will a copy of DOS have any real value in 75
years?)  Such lengthy terms mock the Constitutional phrase "for a
limited time" as used in the section that authorizes patents and
copyrights. Just recently Congress considered extending the term to an
even more absurd 100 years.

Perhaps you're thinking of patents? Until recently, patent terms were
17 years from grant. Now they're 20 years from filing or 17 years from
grant, whichever is longer. Although these terms are shorter than
copyright terms, given the rapid pace of modern technology they are
still far too long.

Making patents even more of a problem is the abysmal state of the
patent system. Its examiners (most of whom are substandard engineers
unable to get jobs in real life, and/or lawyer wannabees getting a
free law school education from Uncle Sam) routinely grant thousands of
patents on obvious, trivial "inventions" or on things for which
abundant prior art exists. Companies routinely exploit this sad state
of affairs to create "landmines" to sabotage legitimate competition,
as opposed to protecting any substantial investments of their own.

The most important (and by far the most odious) characteristic of a
patent is that independent reinvention is not a defense to a claim of
infringement; you can be denied the right to use your own completely
independent work. The laws of physics and mathematics are the same for
everyone, and throughout history they (and the inventions that follow
from them) have often been independently (re)discovered by many people
at around the same time. For the law to grant exclusive "ownership" of
laws of nature to those with the best paid lawyers is the height of
human arrogance. (Yes, I know that in theory, only inventions, not
physical laws can be patented, and that patent rights are supposed to
go to the first inventor, not to the one with the most money. But
the practice is vastly different from the theory.)

I didn't really want to get into a deep discussion of intellectual

property on this list, but as you can probably tell by now this is one
of my hot buttons. For more on the trouble with patents, see my web page

http://www.qualcomm.com/people/pkarn/patents.html

--Phil

From karn@qualcomm.com Tue Oct 15 17:16:26 1996
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id RAA14694 for <hfsig@tapr.org>; Tue, 15 Oct 1996 17:16:24 -0500 (CDT)
Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id PAA12458; Tue, 15 Oct 1996 15:15:49 -0700 (PDT)
Date: Tue, 15 Oct 1996 15:15:49 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199610152215.PAA12458@servo.qualcomm.com>
To: Robert.Glassey@nmp.nokia.com
CC: hfsig@tapr.org
In-reply-to: <H0000292028b3749@MHS> (Robert.Glassey@nmp.nokia.com)
Subject: Re: [HFSIG:1636] Re: ARRL DCC and the old SS thread

>A while back I posted a set of guidelines intended as a first step along
>these lines on SS-SIG, but it appears gun-blazing faith and blindness is
>the prefered course of action. - This does nothing to instill confidance
>amounst the critics.

By chance are you going to the AMSAT annual meeting in Tucson? I
signed up to give a talk on spread spectrum, and I'm thinking I ought
to orient it to a discussion of the points you've been making
recently. I could title it something like "When (and When Not) To
Spread", along the lines of the Viterbi papers in IEEE Communications
magazine over the past 15 years or so.

Phil

From karn@qualcomm.com Tue Oct 15 19:02:29 1996
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id TAA19323 for <hfsig@tapr.org>; Tue, 15 Oct 1996 19:02:26 -0500 (CDT)
Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id RAA12677; Tue, 15 Oct 1996 17:00:02 -0700 (PDT)
Date: Tue, 15 Oct 1996 17:00:02 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199610160000.RAA12677@servo.qualcomm.com>
To: "Breon, Roy K" <rkb1@rfpo1.rfc.comm.harris.com>
CC: hfsig@tapr.org
In-reply-to: <325E45D8@smtpgate.rfc.comm.harris.com> (rkb1@rfpo1.rfc.comm.harris.com)
Subject: Re: [HFSIG:1646] Re: ARRL DCC and the old SS thread

>Speaking of interfering signals -- noise is a form of interference.  Using 
>our modem, we can actually receive error free data with received signals 
>having negative signal to noise ratios.  In other words, the signal is below 
>the noise.  This has obvious benefits for the user.

This statement is either wrong or meaningless. What does "negative
signal to noise ratio" mean? If you mean Eb/N0 ratios below -1.6 dB, I
have this bridge in New York you might be interested in buying. Rumor
has it that it's going to be named after Claude Shannon.. :-)

But if you mean a negative signal-to-noise ratio in the operating
bandwidth, then your statement is meaningless without specifying both
the operating bandwidth and the user data rate. It's easy to make a
modem that operates at "negative signal-to-noise ratios" when the
bandwidth is much higher than the data rate -- spread spectrum and low
rate FEC are two well-known ways to do this.

That's why it's much better to just drop the notion of "signal to
noise ratio" when discussing modem performance and talk strictly about
Eb/N0 ratios, because they quantify the performance of a demodulator
in a way that's independent of bandwidth and data rate.

You can compute Eb/N0 from SNR, bandwidth and data rate with the following
formulas:

Eb/N0 = (S/R)/(N/B) = (S/N)/(R/B)

Eb = energy per bit, joules
N0 = noise spectral density, watts/hz (joules)
S = signal power, watts
R = user data (*NOT* coded symbol) rate, bits/sec
N = noise power, watts
B = signal bandwidth, hz


--Phil

From jsanford@infi.net Tue Oct 15 19:46:23 1996
Received: from mh004.infi.net (mh004.infi.net [198.22.1.119]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id TAA21146 for <hfsig@tapr.org>; Tue, 15 Oct 1996 19:46:22 -0500 (CDT)
Received: from PENTIUM by mh004.infi.net with SMTP 
	(Infinet-S-3.3) id UAA29017; Tue, 15 Oct 1996 20:46:32 -0400 (EDT)
Message-ID: <3264307C.433@infi.net>
Date: Tue, 15 Oct 1996 20:46:52 -0400
From: Jim Sanford <jsanford@infi.net>
Reply-To: wb4gcs@amsat.org
Organization: WB4GCS
X-Mailer: Mozilla 3.0 (Win16; U)
MIME-Version: 1.0
To: hfsig@tapr.org
Subject: Re: [HFSIG:1654] Re: ARRL DCC and the old SS thread
References: <199610152212.PAA12455@servo.qualcomm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Phil Karn wrote:
> 
> >Why should a company file for a copyright to protect their product????
> >And copyrights expire!! Do you think Microsoft should file for a
> >copyright for DOS? Look, my point here is that a COMPANY has the right
> 
> Every copy of DOS I've ever seen has a Microsoft copyright notice. And
> current US law says that copyrights are automatic; you don't have to
> file for one unless you want to sue for infringement.
> 
> Copyrights have a term of the life of the author plus 50 years,
> or for "works for hire", 100 years from the date of creation or 75
> years from first publication, whichever comes first.
> 
> These terms are so long, especially for computer software, as to be
> essentially infinite. (Will a copy of DOS have any real value in 75
> years?)  Such lengthy terms mock the Constitutional phrase "for a
> limited time" as used in the section that authorizes patents and
> copyrights. Just recently Congress considered extending the term to an
> even more absurd 100 years.
> 
> Perhaps you're thinking of patents? Until recently, patent terms were
> 17 years from grant. Now they're 20 years from filing or 17 years from
> grant, whichever is longer. Although these terms are shorter than
> copyright terms, given the rapid pace of modern technology they are
> still far too long.
> 
> Making patents even more of a problem is the abysmal state of the
> patent system. Its examiners (most of whom are substandard engineers
> unable to get jobs in real life, and/or lawyer wannabees getting a
> free law school education from Uncle Sam) routinely grant thousands of
> patents on obvious, trivial "inventions" or on things for which
> abundant prior art exists. Companies routinely exploit this sad state
> of affairs to create "landmines" to sabotage legitimate competition,
> as opposed to protecting any substantial investments of their own.
> 
> The most important (and by far the most odious) characteristic of a
> patent is that independent reinvention is not a defense to a claim of
> infringement; you can be denied the right to use your own completely
> independent work. The laws of physics and mathematics are the same for
> everyone, and throughout history they (and the inventions that follow
> from them) have often been independently (re)discovered by many people
> at around the same time. For the law to grant exclusive "ownership" of
> laws of nature to those with the best paid lawyers is the height of
> human arrogance. (Yes, I know that in theory, only inventions, not
> physical laws can be patented, and that patent rights are supposed to
> go to the first inventor, not to the one with the most money. But
> the practice is vastly different from the theory.)
> 
> I didn't really want to get into a deep discussion of intellectual
> property on this list, but as you can probably tell by now this is one
> of my hot buttons. For more on the trouble with patents, see my web page
> 
> http://www.qualcomm.com/people/pkarn/patents.html
> 
> --Phil
Phil:
You & P. J. Plauger . . . . now how do we CHANGE this stuff?

Jim

From rkb1@rfpo1.rfc.comm.harris.com Wed Oct 16 08:25:24 1996
Received: from adm01.rfc.comm.harris.com (adm01.rfc.comm.harris.com [147.177.128.2]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id IAA21124 for <hfsig@tapr.org>; Wed, 16 Oct 1996 08:25:20 -0500 (CDT)
Received: from smtpgate.rfc.comm.harris.com ([147.177.5.94]) by adm01.rfc.comm.harris.com (8.6.12/8.6.9) with SMTP id JAA34001 for <hfsig@tapr.org>; Wed, 16 Oct 1996 09:25:16 -0400
Received: by smtpgate.rfc.comm.harris.com with Microsoft Mail
	id <3264E122@smtpgate.rfc.comm.harris.com>; Wed, 16 Oct 96 09:20:34 DST
From: "Breon, Roy K" <rkb1@rfpo1.rfc.comm.harris.com>
To: "'hfsig@tapr.org'" <hfsig@tapr.org>
Subject: [HFSIG:1646] Re: ARRL DCC and the old SS thread
Date: Wed, 16 Oct 96 09:26:00 DST
Message-ID: <3264E122@smtpgate.rfc.comm.harris.com>
Encoding: 28 TEXT
X-Mailer: Microsoft Mail V3.0


On October 11 I posted a note regarding our HF modem technology and 
philosophy.  Many of you wrote me and asked for the source for the 
MIL-STD-188-110A describing the HF waveforms.

Unclassified military specifications, military standards, and many other 
"public" documents can be obtained from :

Defense Printing Service
700 Robbins Avenue
Philadelphia, PA  19111-5094
215-697-2626

When a specification is issued, it has a revision level letter.  Small or 
proposed changes are usually attached by means of Change Notices.  At some 
point, someone decides to issue a new revision incorporating the accumulated 
Change Notices.  You usually want to ask for the latest revision of the 
documents with any Change Notices that may be outstanding.


Hope this helps.

Roy K. Breon
Manager, Marketing
Harris Corporation
RF Communications Division


From rkb1@rfpo1.rfc.comm.harris.com Thu Oct 17 10:38:43 1996
Received: from adm01.rfc.comm.harris.com (adm01.rfc.comm.harris.com [147.177.128.2]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id KAA05126 for <hfsig@tapr.org>; Thu, 17 Oct 1996 10:38:41 -0500 (CDT)
Received: from smtpgate.rfc.comm.harris.com ([147.177.5.94]) by adm01.rfc.comm.harris.com (8.6.12/8.6.9) with SMTP id NAA04209 for <hfsig@tapr.org>; Wed, 16 Oct 1996 13:58:24 -0400
Received: by smtpgate.rfc.comm.harris.com with Microsoft Mail
	id <32652126@smtpgate.rfc.comm.harris.com>; Wed, 16 Oct 96 13:53:42 DST
From: "Breon, Roy K" <rkb1@rfpo1.rfc.comm.harris.com>
To: "'hfsig@tapr.org'" <hfsig@tapr.org>
Subject: RE: [HFSIG:1656] Re: ARRL DCC and the old SS thread
Date: Wed, 16 Oct 96 13:57:00 DST
Message-ID: <32652126@smtpgate.rfc.comm.harris.com>
Encoding: 60 TEXT
X-Mailer: Microsoft Mail V3.0


Phil  et al ---

I don't disagree with what you said.  I mentioned Eb/N0 but was giving a 
more simplistic comment in the paragraph on which you commented.  Walt 
Dubose has stated what I was referring to.  In other words, the signal would 
be below the noise level when a 3 kHz receive bandwidth is used. In most 
situations, with most radios, the operating bandwidth of the radios is fixed 
at a nominal 3 kHz bandwidth.  For the most versatile use of our modems, we 
stick with that bandwidth and just select various waveforms and data rates , 
either manually or automatically, to fill it up.  In some very automated 
systems, receive and transmitted bandwidth can be changed on the fly.  We 
have also done special systems where the HF bandwidth is 1 MHz.  In these 
systems you can either have a very high data rate or use processing gain to 
really pull the signal out of the noise and/or jamming.

Also, as I stated in my post, we consider some modes of the modem to be a 
spread spectrum type waveform because the full 3 kHz bandwidth would not be 
necessary to transmit that data rate if standard FSK were used.  I believe I 
stated that a slower data rate was used.  As you are probably aware, we also 
use various coding, interleaving, and in band diversity techniques the 
choice of which depends upon many factors.

By the way, since you mention Claude Shannon, he was on my Doctoral oral 
exam committee at MIT.

Also, I always wondered who bought that bridge.  Now I know that you "have " 
it.  That must be an interesting off topic story in itself   ;-)


Roy Breon
Harris Corp.
RF Communications division

 ----------
From: Phil Karn
To: hfsig@tapr.org
Subject: [HFSIG:1656] Re: ARRL DCC and the old SS thread
Date: Tuesday, October 15, 1996 8:19PM

<snipped>

This statement is either wrong or meaningless. What does "negative
signal to noise ratio" mean? If you mean Eb/N0 ratios below -1.6 dB, I
have this bridge in New York you might be interested in buying. Rumor
has it that it's going to be named after Claude Shannon.. :-)

But if you mean a negative signal-to-noise ratio in the operating
bandwidth, then your statement is meaningless without specifying both
the operating bandwidth and the user data rate. It's easy to make a
modem that operates at "negative signal-to-noise ratios" when the
bandwidth is much higher than the data rate -- spread spectrum and low
rate FEC are two well-known ways to do this.

That's why it's much better to just drop the notion of "signal to
noise ratio" when discussing modem performance and talk strictly about
Eb/N0 ratios, because they quantify the performance of a demodulator
in a way that's independent of bandwidth and data rate.

<snipped>  

From karn@unix.ka9q.ampr.org Thu Oct 17 10:41:37 1996
Received: from unix.ka9q.ampr.org (root@unix.ka9q.ampr.org [129.46.90.35]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id KAA05289 for <hfsig@tapr.org>; Thu, 17 Oct 1996 10:41:35 -0500 (CDT)
Received: (from karn@localhost) by unix.ka9q.ampr.org (8.7.4/8.7.3) id BAA05073; Thu, 17 Oct 1996 01:52:08 -0700 (PDT)
Date: Thu, 17 Oct 1996 01:52:08 -0700 (PDT)
Message-Id: <199610170852.BAA05073@unix.ka9q.ampr.org>
From: Phil Karn <karn@unix.ka9q.ampr.org>
To: tcp-group@ucsd.edu, hfsig@tapr.org
Subject: New Viterbi decoder release

Hi. For anyone interested I have released a new version 2.0 of my
Viterbi decoder routines. This release is substantially faster (50%)
than my previous version (1.1). The gains came mainly from a change in
the way that final decisions are made on the decoded data bits (I
switched from the "register exchange" method to the "traceback"
method) and also from continued groveling over the code. Thanks to the
longer path memories that are practical with the traceback scheme, BER
performance is also slightly improved, though the difference is
probably significant only when decoding a high rate punctured code.

The decoding speed on a 133 MHz Pentium is about 259 kilobits/sec for
the NASA standard rate 1/2 K=7 convolutional code.

Two versions of the decoder are provided. The first operates on
finite-size 'tailed' packets as before. The second is written as a
UNIX filter and can operate on a continuous stream of data, closely
emulating a hardware Viterbi decoder.

I've updated my ham radio web page with pointers to the new distributions:

http://www.qualcomm.com/people/pkarn/ham.html

--Phil

From RLANIER@mailb.harris.com  Thu Oct 17 10:48:51 1996
Received: from sol.corp.Harris.COM (sol.corp.harris.com [137.237.25.4]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id KAA05910 for <hfsig@tapr.org>; Thu, 17 Oct 1996 10:48:49 -0500 (CDT)
Received: from mailb.harris.com by sol.corp.Harris.COM (8.6.12/Kurts Special version 2.0)
	id NAA08985; Wed, 16 Oct 1996 13:09:05 -0400
Received: from ccMail by mailb.harris.com
  (IMA Internet Exchange 1.04b) id 26516550; Wed, 16 Oct 96 13:07:33 -0400
Mime-Version: 1.0
Date: Wed, 16 Oct 1996 13:08:26 -0400
Message-ID: <26516550@mailb.harris.com>
From: RLANIER@mailb.harris.com (RLANIER)
Subject: Re: [HFSIG:1649] Re: Why things are the way they are
To: hfsig@tapr.org
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part

>My problem is most definitely NOT with the fact that commercial 
>amateur products cost money.
     
>My problem *is* that they come so often as black boxes. Sure, they 
>generally work as advertised. But they generally fail to perform a 
>more important function, which is to give the amateur who buys them 
>the opportunity to learn as much as he wants about how the device 
>functions.
     
     I still cannot understand your rational for insisting that companies 
     supply source code and/or schematics. Should Sun supply the source 
     code for their operating systems? Of course not. Why? Because if they 
     did, hackers and the like could have a working system WITHOUT ever 
     paying Sun one penny.
     
     The amateur market is no different. Sure we want to encourage 
     experimentation. Join a club, find out those involved in this area, 
     read the books supplied by ARRL and others and if that isn't enough, 
     there is plenty of additional material in electrical engineering 
     books. But don't insist that companies give away the very thing they 
     have put alot of effort and money into.

     
> ...amateur service is supposed to be all about -- self-motivated, 
>hands-on, technical education and training.
     
     This is only one facet of ham radio. Some just want to go for the next 
     award or "chew the fat." And others, like us, want to explore the 
     technical aspects and develop the next-generation radios.
     
> ...cell phones and other commercial systems have made ham radio all 
>but irrelevant for emergency communications, and the Internet has made 
>ham radio essentially irrelevant in the "international good will" 
>category.
     
     I don't see how cell phones have made amateur radio obselete. They 
     still cost money for the phones and even more for the service. A 
     simple CW transceiver running into a dipole is about as simple as it 
     gets and this is also the cheapest. And if your talking to someone, at 
     least you can hear them. With a computer, you can't.



     73s de
     Tony,  KE4ATO

     

From Robert.Glassey@nmp.nokia.com Thu Oct 17 11:05:25 1996
Received: from noknic.nokia.com (noknic.nokia.com [131.228.6.10]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id LAA07921 for <hfsig@tapr.org>; Thu, 17 Oct 1996 11:05:23 -0500 (CDT)
From: Robert.Glassey@nmp.nokia.com
Received: from samail01.nmp.nokia.com (samail01.nmp.nokia.com [131.228.240.6]) by noknic.nokia.com (8.6.9/8.6.9) with ESMTP id TAA20172 for <hfsig@tapr.org>; Wed, 16 Oct 1996 19:31:15 +0200
Received: from  by samail01.nmp.nokia.com with SMTP
	(1.37.109.16/16.2) id AA051883346; Wed, 16 Oct 1996 19:29:09 +0300
X-Openmail-Hops: 2
Date: Wed, 16 Oct 96 13:18:42 +0100
Message-Id: <H00002920292f5f8@MHS>
In-Reply-To: <263eccd0@mailb.harris.com>
Subject: [HFSIG:1653] Re: SS thread
Sender: Robert.Glassey@nmp.nokia.com
To: hfsig@tapr.org

>  Why not follow the existing amateur rules that all ready exist? We 
>  shouldn't cause harmfull interference, period. Neither should someone

>  running a SSB system at 100 watts. If we follow good design practices

>  and workmanship, which all homebrewers should, then we shouldn't have

>  any problems. 

One of the first rules that has worked for non-speading modes, is to
keep your transmissions within a certian bandwidth. Narrow band
receivers are designed to cope with bandwidth limited interference. Once
you set this rule asside, your in a new realm of what will and will not
cause interference. The old rules dont work for SS, we must consider
what the new rules should be.

Its not just a case of quality of equipemnt, no doubt you will endevour
to make high quality equipment, its a question of inter-mode
compatibility.

>  I think what would work even better is if a club or group would 
>  conduct tests of SS and "regular" systems, side-by-side, and listen 
>  for interference. What better way than to demonstrate it? 

I'm sure it will help, but it will leave many questions unanswered.
There are as many variations as there are people to implement them. Some
will work others wont. We need some way to sorting out the good from the
bad and having something to aim for to ensure we are not wasting our
efforts.

>      Of course. You always want to start small, test your idea and go

Yip, I had a slightly different meaning in mind. I was thinking of
starting with systems that we can be certian will not interfere even if
they are quite restrictive. As we gain more experiance we can remove the
restrictions as we discover what the technical aspects are. Low power is
a start, directional antennas would be a good idea, high procesing gains
would help, high frequencies would help. Let go with the most compatible
system we can think of, then work out the tradeoffs between say
frequency and data rate or whatever.

Cheers,

Rob

From k5yfw@www.kelly-afb.org Thu Oct 17 11:53:37 1996
Received: from www.kelly-afb.org (www.kelly-afb.org [204.214.204.10]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id LAA10380 for <hfsig@tapr.org>; Thu, 17 Oct 1996 11:53:35 -0500 (CDT)
Received: (from k5yfw@localhost) by www.kelly-afb.org (8.7.1/8.7.1) id LAA18556; Thu, 17 Oct 1996 11:54:33 -0500 (CDT)
From: Walt DuBose - K5YFW <k5yfw@www.kelly-afb.org>
Message-Id: <199610171654.LAA18556@www.kelly-afb.org>
Subject: Re: [HFSIG:1661] Re: Why things are the way they are
To: hfsig@tapr.org
Date: Thu, 17 Oct 1996 11:54:33 -0500 (CDT)
Cc: wa3pay-kc5bji@stic.net (Teri Thomas), thomas@uthscsa.edu (Charles Thomas),
        choffman@pelican.davlin.net (Ric Hoffman),
        102651.2105@compuserve.com (Al Uvietta),
        valdez1@samhou-basops.army.mil (Ed Valdez)
In-Reply-To: <26516550@mailb.harris.com> from "RLANIER" at Oct 17, 96 11:11:34 am
Reply-To: k5yfw@www.kelly-afb.org
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text

In Tony's message he writes:
[stuff deleted]
> > ...cell phones and other commercial systems have made ham radio all 
> >but irrelevant for emergency communications, and the Internet has made 
> >ham radio essentially irrelevant in the "international good will" 
> >category.
>      
>      I don't see how cell phones have made amateur radio obselete. They 
>      still cost money for the phones and even more for the service. A 
>      simple CW transceiver running into a dipole is about as simple as it 
>      gets and this is also the cheapest. And if your talking to someone, at 
>      least you can hear them. With a computer, you can't.
> 
> 
> 
>      73s de
>      Tony,  KE4ATO
> 

	I have to agree with Tony.  

	Cellphone "cells" are the first communications media to become 
	overloaded and usless in an emergency.

	Also, we have pointed out to much of the "community" that
	cellphones can not run "net" operations and the "community" agrees.

	The three major radio clubs in San Antonio and the City CD,
	over the last couple of months, have averaged 1.5 communications
	events per week.  This is providing communications for "community"
	events that they cannot get by using cellphones, trunking radio 
	systems or GMRS.  

	"Nets" are the most valuable communications asset during an emergency.
	Local and state governments _CANNOT_ maintain a full time cadre of 
	paid and trained radio operators, with equipment...taxpayers will 
	never allow them to do this.  Thus, the trained hamradio operator 
	with his equipment becomes a valuable asset to local and state 
	governments during emergencies.

	Walt

=======================================================================
| The MicroSoft operating system didn't get as bad as it is overnight,|
| it has taken over 10 years of careful, calculated development.      |
=======================================================================
|				    |				      |
|                                   | The greatest dangers to liberty |
| Walt DuBose - K5YFW               | lurk in insidious encroachment  |
| E-Mail k5yfw@www.kelly-afb.org    | by men of zeal, well-meaning    |
| Business Telephone: (210)925-6081 | but without understanding.      | 
|     Home Telephone: (210)696-3196 | 				      |
|                                   |   - Justice Louis D. Brandeis   |
|     	                            |   			      |
=======================================================================

From karn@qualcomm.com Thu Oct 17 18:32:42 1996
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id SAA27299 for <hfsig@tapr.org>; Thu, 17 Oct 1996 18:32:40 -0500 (CDT)
Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id QAA18104; Thu, 17 Oct 1996 16:32:08 -0700 (PDT)
Date: Thu, 17 Oct 1996 16:32:08 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199610172332.QAA18104@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <26516550@mailb.harris.com> (RLANIER@mailb.harris.com)
Subject: Re: [HFSIG:1661] Re: Why things are the way they are

     I still cannot understand your rational for insisting that companies 
     supply source code and/or schematics. Should Sun supply the source 
     code for their operating systems? Of course not. Why? Because if they 
     did, hackers and the like could have a working system WITHOUT ever 
     paying Sun one penny.

Again, copyrights are designed to deal with that issue, though I don't
want to veer off again into a general discussion on intellectual
property.

Your choice of example helps make my original point. Precisely because
of the proprietary nature of most commercial operating systems,
efforts such as FreeBSD, NetBSD and Linux have sprung up to make a
nonproprietary operating system, with full source code, readily
available to anyone. And the GNU project has succeeded in producing a
large collection of utilities under the same terms.

In many cases the freely available software is as good as or even
better than the proprietary stuff. This is partly because a suitably
motivated and talented software volunteer can often outperform a paid
programmer who is just doing it for the money, and also because the
widespread availability of the software creates a much larger pool of
programming talent that can contribute to the project.

I did *not* say that amateur equipment manufacturers should be
required to disclose their source code. That is their right. I was
merely lamenting the fact that they have chosen not to do so. This
creates an opportunity for an independent volunteer amateur effort
very similar to the Linux and GNU projects to fill the gaps left by
the increasingly proprietary commercial vendors, and perhaps to
outperform them.

Phil

From karn@qualcomm.com Thu Oct 17 18:44:00 1996
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id SAA27701 for <hfsig@tapr.org>; Thu, 17 Oct 1996 18:43:58 -0500 (CDT)
Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id QAA18128; Thu, 17 Oct 1996 16:43:27 -0700 (PDT)
Date: Thu, 17 Oct 1996 16:43:27 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199610172343.QAA18128@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <26516550@mailb.harris.com> (RLANIER@mailb.harris.com)
Subject: Re: [HFSIG:1661] Re: Why things are the way they are

> ...amateur service is supposed to be all about -- self-motivated, 
>hands-on, technical education and training.
     
     This is only one facet of ham radio. Some just want to go for the next 
     award or "chew the fat." And others, like us, want to explore the 
     technical aspects and develop the next-generation radios.

As I've said many times, I have no problem with those who are simply out
to enjoy themselves. A volunteer service wouldn't last long if you banned
having fun, because what other reason would there be to participate?

My problem is with the fact that hams make up only about 0.5% of the
US population, so if we're to keep some increasingly valuable spectrum
to ourselves we have no choice but to sell ourselves to the remaining
99.5% on the basis of something other than how much fun the 0.5% is
having. That means public service, education, etc.

     I don't see how cell phones have made amateur radio obselete. They 
     still cost money for the phones and even more for the service. A 
     simple CW transceiver running into a dipole is about as simple as it 
     gets and this is also the cheapest. And if your talking to someone, at 
     least you can hear them. With a computer, you can't.

I could repeat the story of how I finally came to buy a cell phone,
but you've probably heard it before. Suffice to say I had an extremely
frustrating experience with using ham radio to summon help in a road
emergency (serious injury) situation when a cell phone would have made
a direct 911 call easy. As for cost, portable cell phones are now
substantially cheaper than their nearest ham equivalent (the 2m HT),
and service rates are quite low if you rarely make calls. (Even an
unregistered phone can still make 911 calls.)

CW is completely irrelevant for any credible modern emergency situation.

Phil


From karn@qualcomm.com Thu Oct 17 18:50:20 1996
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id SAA28007 for <hfsig@tapr.org>; Thu, 17 Oct 1996 18:50:18 -0500 (CDT)
Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id QAA18141; Thu, 17 Oct 1996 16:49:46 -0700 (PDT)
Date: Thu, 17 Oct 1996 16:49:46 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199610172349.QAA18141@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <32652126@smtpgate.rfc.comm.harris.com> (rkb1@rfpo1.rfc.comm.harris.com)
Subject: Re: [HFSIG:1659] Re: ARRL DCC and the old SS thread

>I don't disagree with what you said.  I mentioned Eb/N0 but was giving a 
>more simplistic comment in the paragraph on which you commented.  Walt 

Right, I was just trying to inject some rigor into what had started to
sound like a Harris marketing blurb. :-)

>Also, as I stated in my post, we consider some modes of the modem to be a 
>spread spectrum type waveform because the full 3 kHz bandwidth would not be 
>necessary to transmit that data rate if standard FSK were used.  I believe I 

Indeed. I've made this exact point for some time to show that we hams
can use the SSB-bandwidth equipment we already have to experiment with
spread-spectrum techniques on a "scaled down" basis. All the SS stuff
would be done purely in software, which is ideal for inexpensive
experimentation.

Phil

From karn@qualcomm.com Thu Oct 17 19:00:30 1996
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id TAA28185 for <hfsig@tapr.org>; Thu, 17 Oct 1996 19:00:27 -0500 (CDT)
Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id QAA18150; Thu, 17 Oct 1996 16:59:56 -0700 (PDT)
Date: Thu, 17 Oct 1996 16:59:56 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199610172359.QAA18150@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <199610171654.LAA18556@www.kelly-afb.org> (message from Walt DuBose - K5YFW on Thu, 17 Oct 1996 12:46:44 -0500 (CDT))
Subject: Re: [HFSIG:1663] Re: Why things are the way they are

	Cellphone "cells" are the first communications media to become 
	overloaded and usless in an emergency.

I wish I had a nickle for each time I've heard that said. If our only
advantage vs cellular telephony in an emergency are our generous
spectrum allocations and tiny numbers, then we're in serious trouble
as the obvious fix is to reallocate our spectrum to cellular telephony
where it can be used more efficiently.

Yet I dispute the actual claim. There are many more audio channels in
my one local cell site than are available in all the ham repeaters in
town.  And cellular system capacity is expanding so rapidly as to make
anecdotes even about relatively recent events (like the Loma Prieta
and Northridge earthquakes) rather meaningless as future predictions.

If I needed to make a phone call in an emergency I think I'd get
through faster by just pressing the SND key until I got through than
to wait for the local repeater to clear to use the autopatch.

>"Nets" are the most valuable communications asset during an emergency.

Assuming that is true (which I don't -- nets and point-to-point mode
operation each has its place), it is not true that net-style operation
is unique to amateur radio. Trunking systems are already widespread.
Adding net-style operation to CDMA digital cellular has been an
ongoing government-sponsored project at Qualcomm for several years.


Phil

From jsanford@infi.net Thu Oct 17 20:36:14 1996
Received: from mh004.infi.net (mh004.infi.net [198.22.1.119]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id UAA02455 for <hfsig@tapr.org>; Thu, 17 Oct 1996 20:36:12 -0500 (CDT)
Received: from PENTIUM by mh004.infi.net with SMTP 
	(Infinet-S-3.3) id VAA26305; Thu, 17 Oct 1996 21:36:21 -0400 (EDT)
Message-ID: <3266DF2D.3F93@infi.net>
Date: Thu, 17 Oct 1996 21:36:45 -0400
From: Jim Sanford <jsanford@infi.net>
Reply-To: wb4gcs@amsat.org
Organization: WB4GCS
X-Mailer: Mozilla 3.0 (Win16; U)
MIME-Version: 1.0
To: hfsig@tapr.org
CC: w4hfz@amsat.org, ko4lw@amsat.org
Subject: Re: [HFSIG:1664] Re: Why things are the way they are
References: <199610172332.QAA18104@servo.qualcomm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Phil Karn wrote:
> 
>      I still cannot understand your rational for insisting that companies
>      supply source code and/or schematics. Should Sun supply the source
>      code for their operating systems? Of course not. Why? Because if they
>      did, hackers and the like could have a working system WITHOUT ever
>      paying Sun one penny.
> 
> Again, copyrights are designed to deal with that issue, though I don't
> want to veer off again into a general discussion on intellectual
> property.
> 
> Your choice of example helps make my original point. Precisely because
> of the proprietary nature of most commercial operating systems,
> efforts such as FreeBSD, NetBSD and Linux have sprung up to make a
> nonproprietary operating system, with full source code, readily
> available to anyone. And the GNU project has succeeded in producing a
> large collection of utilities under the same terms.
> 
> In many cases the freely available software is as good as or even
> better than the proprietary stuff. This is partly because a suitably
> motivated and talented software volunteer can often outperform a paid
> programmer who is just doing it for the money, and also because the
> widespread availability of the software creates a much larger pool of
> programming talent that can contribute to the project.
> 
> I did *not* say that amateur equipment manufacturers should be
> required to disclose their source code. That is their right. I was
> merely lamenting the fact that they have chosen not to do so. This
> creates an opportunity for an independent volunteer amateur effort
> very similar to the Linux and GNU projects to fill the gaps left by
> the increasingly proprietary commercial vendors, and perhaps to
> outperform them.
> 
> Phil
Since I either tossed the match or initial gallon of gasoline on this
fire, it's time for me to throw another . . .

I do not expect radio manufacturers to publish their source code. 
Although a lot could be improved if they did, just look at the
tremendous improvement Chipswitch made to the Uniden radios --what a
great IF rig!
Look at the problems the Ubiquitous FT736 has -- a computer command set
which is practically one-way, vulnerable to spurious transmitter
lock-ups, and basically primitive.  A little cooperation on Yaesu's part
could allow someone to improve it (a la Chipswitch/Uniden) improve a
gross deficiency in a pretty good radio, and all at ZERO cost to Yaesu. 
Of course the consequence could be even MORE 736's sold . . .

I do, however, _DEMAND_!!!!  that anyone putting a waveform on the ham
bands publish the details of it, so that it can be understood, and
perhaps duplicated in DSP by other folks.  Proprietary waveforms on the
ham bands is inexcusable, unacceptable, and should be discouraged by
hams taking their checkbook elsewhere.  Henry was trying hard to sell
Clover to the Military (at least from all the stuff I saw as a Naval
officer), and when other, better systems made them non-players, they
tried to recover their costs from paying hams -- shades of Bill Gates. 
I notice that they're finally dropping their prices . . . . Clover may
be a good system (althought the military and NATO didn't think so), but
until there's sufficient information in the PUBLIC DOMAIN, it should be
ignored.  

Phil and Johan (and others) are doing enough with open algorithms to
enhance HF digital communications that we don't need to patronize or
subsidize proprietary waveforms.  The fact that they choose to publish
their code is merely icing on the cake.

So, in summary:  If you've got a proprietary waveform, take it out of
the ham bands -- go find a gullible congressman, general, or admiral to
buy it.  Hams, if you want to push the state of the art on HF digital
communications, keep your $$ away from the proprietary stuff, and go
with the guys who are CONTRIBUTING SIGNIFICANTLY TO THE STATE OF THE ART
-- part of what Ham Radio is all about, STILL!

Feel free to flame on -- I've been screamed at by ADM Rickover, so have
a ball.  I'm willing to listen to any reason why Phil or Johan et al
might choose to keep their code private, but inflexible on the
proprietary waveform issue.

73, Jim
WB4GCS@amsat.org

From wd5ivd@tapr.org Fri Oct 18 00:11:37 1996
Received: (from wd5ivd@localhost) by tapr.org (8.7.5/8.7.3/1.9) id AAA12704 for hfsig@tapr.org; Fri, 18 Oct 1996 00:11:37 -0500 (CDT)
From: Greg Jones <wd5ivd@tapr.org>
Message-Id: <199610180511.AAA12704@tapr.org>
Subject: Wanted: SIG Chair
To: hfsig@tapr.org (HF SIG mailing)
Date: Fri, 18 Oct 1996 00:11:36 -0500 (CDT)
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

With all the red hot debate, maybe this is the time to say that this SIG
needs a Chair to replace Johan.

Johan asked to be replaced at the ARRL and TAPR DCC in Seattle.

Basically, Johan has other outside commitments that are requiring more of
his time and he would like to see some one fresh take over the SIG.  Johan
is the founder of this SIG and both he and I would really like to see the
direction he began continue.  As Johan stated at the DCC, he is not going
away, he just needs someone to take over the position of chair.

Responsibilities are simple:

1. Watch over this list.  Which means try to help focus technical discussion
and reply to those that send unsub and sub messages to the list :-)

2. Write a short overview of SIG activities twice a year for the TAPR PSR

3. Help organize the HF SIG meeting at the ARRL and TAPR DCC

4. Organize or assign some one to handle the HF SIG ftp area.

5. Other tasks as assigned by the SIG chair them self.


Those are the basics.  Johan has been able to go way beyond these simple
tasks, but anyone starting now would only need to do these.  These simple
tasks allow the SIG to run in an orderly fashion and provide more than just
a mailing list on HF digital topics.

I believe some of the key elements required to be a good SIG chair include
looking for connections to other areas, forwarding messages of interest to
the PSR editor for potential articles, and trying to look for concepts and
projects that can be moved from the SIG to a much wider audience.

I'll let Johan add additional comments.

This is the time to find a new chair and someone must rise to the task of
being chair.

If you think you might be interested, please contact Johan or myself.

Cheers - Greg, WD5IVD
Pres TAPR

From rs@ife.ee.ethz.ch Fri Oct 18 02:50:40 1996
Received: from ife.ee.ethz.ch (ife-ife1.ee.ethz.ch [129.132.25.65]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id CAA19496 for <hfsig@tapr.org>; Fri, 18 Oct 1996 02:50:37 -0500 (CDT)
Received: from gillespie.ee.ethz.ch (rs@gillespie.ee.ethz.ch [129.132.25.135]) by ife.ee.ethz.ch (8.8.0/8.8.0) with SMTP id JAA07637 for <hfsig@tapr.org>; Fri, 18 Oct 1996 09:50:33 +0200 (MET DST)
From: Rolf Sommerhalder <rs@ife.ee.ethz.ch>
Received: by gillespie.ee.ethz.ch (8.6.11) id JAA19000; Fri, 18 Oct 1996 09:50:32 +0200
Message-Id: <199610180750.JAA19000@gillespie.ee.ethz.ch>
Subject: Re: [HFSIG:1668] Re: Why things are the way they are
To: hfsig@tapr.org
Date: Fri, 18 Oct 1996 09:50:32 +0200 (MET DST)
In-Reply-To: <3266DF2D.3F93@infi.net> from Jim Sanford at "Oct 17, 96 08:54:57 pm"
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Jim wrote:
> ...
> I do, however, _DEMAND_!!!!  that anyone putting a waveform on the ham
> bands publish the details of it, so that it can be understood, and
> perhaps duplicated in DSP by other folks.  Proprietary waveforms on the
> ham bands is inexcusable, unacceptable, and should be discouraged by
> hams taking their checkbook elsewhere.  
> ...
> Phil and Johan (and others) are doing enough with open algorithms to
> enhance HF digital communications that we don't need to patronize or
> subsidize proprietary waveforms.  The fact that they choose to publish
> their code is merely icing on the cake.
> ...

I am thinking roughly along the same lines that _specifications_ should be
laid open, even though _implementations_ may be kept as a trade secret
by the vendors (in the HAM as well as in commercial markets). Of course,
the specifications must be precise enough, so that other implementors can
produce compatible, i.e. fully interopable, devices.

This is the approach taken by ITU (and many other standardisation bodies as
well) in its recommendations, where in V.42bis for example, only the data
compression algorithms are specified precisely, but no implementation details
are provided.

I have been discussing this issue with the holder of the rights 
on Pactor (-1/-2) for commercial markets some two years ago, and I was
unable to convince him that he could create a bigger market for
Pactor-2 if its specification would be open. Commercial buyers too
are reluctant buying products which come from a single manufacturer (what if
he goes out of business ?  etc.).
I understand that it is tough for the inventors and their
investors to disclose some of their key know-how considering that they want to
recoup their investments and make some profit for the risks they have taken.
In the longer term, I believe, they could do that also in a more open
environment, provided of course that they stay in business by delivering good
products to an expanding market, and that they continue to lead
innovation/evolution. They choose another way, so far.


I guess that the IS-95/CDMA cellular phone standard is an interesting
case which maybe in support of my ideas. Phil might want expand on similar
mechanisms which are applied by his employer to create a new market for CDMA
(which did not even exist before), and to compete against established GSM
technology.


73,
Rolf, HB9CWP

From sailer@ife.ee.ethz.ch Fri Oct 18 02:54:40 1996
Received: from ife.ee.ethz.ch (ife-ife1.ee.ethz.ch [129.132.25.65]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id CAA19565 for <hfsig@tapr.org>; Fri, 18 Oct 1996 02:54:28 -0500 (CDT)
Received: from eldrich.ee.ethz.ch (eldrich.ee.ethz.ch [129.132.25.145]) by ife.ee.ethz.ch (8.8.0/8.8.0) with SMTP id JAA07781 for <hfsig@tapr.org>; Fri, 18 Oct 1996 09:54:21 +0200 (MET DST)
Sender: sailer@ife.ee.ethz.ch
Message-ID: <326737AC.877@ife.ee.ethz.ch>
Date: Fri, 18 Oct 1996 09:54:20 +0200
From: Thomas Sailer <sailer@ife.ee.ethz.ch>
Organization: IfE
X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4m)
MIME-Version: 1.0
To: hfsig@tapr.org
Subject: Re: [HFSIG:1665] Re: Why things are the way they are
References: <199610172343.QAA18128@servo.qualcomm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Phil Karn wrote:

> CW is completely irrelevant for any credible modern emergency situation.
Since ID4 we all know that only CW can save the world :-)

Tom

From karn@qualcomm.com Fri Oct 18 05:47:26 1996
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id FAA24197 for <hfsig@tapr.org>; Fri, 18 Oct 1996 05:47:24 -0500 (CDT)
Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id DAA19284; Fri, 18 Oct 1996 03:46:52 -0700 (PDT)
Date: Fri, 18 Oct 1996 03:46:52 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199610181046.DAA19284@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <326737AC.877@ife.ee.ethz.ch> (message from Thomas Sailer on Fri, 18 Oct 1996 03:12:46 -0500 (CDT))
Subject: Re: [HFSIG:1671] Re: Why things are the way they are

>> CW is completely irrelevant for any credible modern emergency situation.
>Since ID4 we all know that only CW can save the world :-)

I laughed out loud at several points in that movie when I was probably
not supposed to. That was one of them.

It would have been much better had the governments of earth used PGP
and the Internet (both being widely available around the globe) to
coordinate the counterattack. Maybe the aliens wouldn't have figured
it out quite as quickly. :-)

Phil

From RLANIER@mailb.harris.com  Fri Oct 18 08:19:26 1996
Received: from sol.corp.Harris.COM (sol.corp.harris.com [137.237.25.4]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id IAA28720 for <hfsig@tapr.org>; Fri, 18 Oct 1996 08:19:24 -0500 (CDT)
Received: from mailb.harris.com by sol.corp.Harris.COM (8.6.12/Kurts Special version 2.0)
	id JAA11345; Fri, 18 Oct 1996 09:19:18 -0400
Received: from ccMail by mailb.harris.com
  (IMA Internet Exchange 1.04b) id 267837a0; Fri, 18 Oct 96 09:17:46 -0400
Mime-Version: 1.0
Date: Fri, 18 Oct 1996 09:18:35 -0400
Message-ID: <267837a0@mailb.harris.com>
From: RLANIER@mailb.harris.com (RLANIER)
Subject: Re: [HFSIG:1668] Re: Why things are the way they are
To: hfsig@tapr.org
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part

     
>Feel free to flame on -- I've been screamed at by ADM Rickover, so 
>have a ball.  I'm willing to listen to any reason why Phil or Johan et 
>al might choose to keep their code private, but inflexible on the 
>proprietary waveform issue.
     
>73, Jim
>WB4GCS@amsat.org
     
     Look guys, this is getting out of hand!!! If you want to get "into 
     it," please do so off of this list, such as Phil and I have.
     
     I want to clairify, ONCE AND FOR ALL, my position. I think it is great 
     that hams such as Phil, Johan, et al, are working to push the 
     state-of-the-art in ham radio. PLEASE KEEP DOING IT!!! I for one spend 
     as much time as I can doing the same thing. And as I have stated 
     before, I will share my results.
     
     We do so because we like to, because it is FUN! But as I have said 
     before, a company, ANY COMPANY, exists to make money, whether it is to 
     provide a service or to sell a product. And in amateur radio, there is 
     plenty of competition, especially between the "big guns," Yaesu, Icom 
     and Kenwood. These companies work hard to come up with the latest and 
     greatest, so they can make a profit. If Kenwood did some research on 
     the merits of using DSPs in the IF stage and then published it, 
     including source code, Yaesu or Icom could use it to make their next 
     product line. Kenwood just contracted out work for FREE! That is not 
     going to cut it in the business world guys, no matter how much you 
     complain!
     
     Start your own company and rely SOLELY of the profits of that company 
     and I guarantee you will change your mind.
     
     
     73s de
     Tony,  KE4ATO

From rwilliam@cesa4.k12.wi.us Fri Oct 18 16:14:57 1996
Received: from gomer.wiscnet.net (dial.wiscnet.net [144.92.88.11]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id QAA14373 for <hfsig@tapr.org>; Fri, 18 Oct 1996 16:14:56 -0500 (CDT)
Received: from RICKWILLIAMS by gomer.wiscnet.net;
          id QAA482952; 8.6.9W/50; Fri, 18 Oct 1996 16:14:50 -0500
Message-Id: <199610182114.QAA482952@gomer.wiscnet.net>
From: "Rick Williams" <rwilliam@cesa4.k12.wi.us>
To: <hfsig@tapr.org>
Subject: Re: [HFSIG:1652] Ham Radio Clip Art
Date: Fri, 18 Oct 1996 15:56:12 -0500
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


Larry Bush, W5NCD had said:
> Does anyone know of a source of Ham Radio Clip Art?
> I Want to make up my own QSL and calling Cards.
> 


I made up a simple QSL format using a word processor and stock clip art. I
used a globe clip art pattern and a table format using MS Word and make
four duplicates per laser printed page. I can either print small amounts if
I have a need for a few special cards or merely substitute the call sign
and name and address, etc. for different folks.

For example, it was trivial to make up a template for my wife or daughter
to use for their cards. Since they almost never need them, it can be run
off in quantities of four at a time or could use the master for "printing" 
in a copy machine. Tried higher weight paper (like about 90# I think) and
for the most part got it to go thru the machine but that is pushing the
limits.

I will never again purchase QSL cards from a printer. The only way it makes
sense is if you need really large quantities, vis a vis contesting, 
DXpeditioning, or similar multi-thousand quantities, or want multi-color or
picture types with special effects.

Rick, KV9U

From kauten@atl.mindspring.com Tue Oct 22 20:03:21 1996
Received: from itchy.mindspring.com (itchy.mindspring.com [204.180.128.6]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id UAA18308; Tue, 22 Oct 1996 20:02:46 -0500 (CDT)
Received: from Default (user-168-121-27-107.dialup.mindspring.com [168.121.27.107]) by itchy.mindspring.com (8.7.5/8.7.3) with SMTP id VAA08231; Tue, 22 Oct 1996 21:00:21 -0400 (EDT)
Message-Id: <1.5.4.32.19961023010003.006d3abc@pop.atl.mindspring.com>
X-Sender: kauten@pop.atl.mindspring.com
X-Mailer: Windows Eudora Light Version 1.5.4 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 22 Oct 1996 21:00:03 -0400
To: arne_luehrs@grenoble.hp.com, n0aot@amsat.org, rsmith@internetmci.com,
        bgaf@annap.infi.net, mullaneb@mccc.edu, xbrucex@popmail.mcs.net,
        crlbyers@garlic.com, dsp-93@tapr.org, ebossa@acm.org,
        101365.1113@compuserve.com, wd5ivd@tapr.org, hbs@crl.com,
        hfsig@tapr.org, govier02@sarenet.es, k4gvo@america.net,
        jsanford@infi.net, hl1sqi@neptune.samwoo.co.kr, kgoodwin@draper.com,
        kbanke@mage.qualcomm.com, johnson@mmsi.com, 100577.1452@compuserve.com,
        MS16948@LTU.EDU, rsuban@promitheus.maltanet.omnes.net,
        rbiasiot@nji.com, schultew@uni-duesseldorf.de, tedm@voyager.co.nz,
        wb8oue@amsat.org, LANIER.R.A-@smtpgty.bwi.wec.com, twatson@magic1.org,
        wpreez@csir.co.za, ylshih@alumni.caltech.edu
From: "James R. Kauten, MD" <kauten@atl.mindspring.com>
Subject: PC-DSP and PC-SIM Order

As you are aware, many folks expressed an interest in the software: PC-DSP
and PC-SIM by DSP Solutions (http://www.dspsolutions.com).  TAPR also has a
description of the software on their web page (http://www.tapr.org).  In the
most recent PSR-TAPR newsletter there is also a description.  If there are
any other folks interested in purchasing the software other than those of us
who have placed our orders, place your order thru TAPR so that a final order
can be sent in.  We need a minimum order of 21 before an order can be placed.  

Thank you.

Jim Kauten, MD, KO4RQ
=====================================================
James R. Kauten, M.D.,  KO4RQ (kauten@mindspring.com)
=====================================================
Phone:      (404) 355-9537 (Fax)            (404) 355-9515 (Daytime)
Address:  James R. Kauten, M.D.,  95 Collier Road,  Suite 2055
                                             Atlanta, GA,  30305-1955
=====================================================

From karn@unix.ka9q.ampr.org Wed Oct 23 04:57:21 1996
Received: from unix.ka9q.ampr.org (root@unix.ka9q.ampr.org [129.46.90.35]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id EAA13801 for <hfsig@tapr.org>; Wed, 23 Oct 1996 04:57:19 -0500 (CDT)
Received: (from karn@localhost) by unix.ka9q.ampr.org (8.7.4/8.7.3) id CAA03874; Wed, 23 Oct 1996 02:28:53 -0700 (PDT)
Date: Wed, 23 Oct 1996 02:28:53 -0700 (PDT)
Message-Id: <199610230928.CAA03874@unix.ka9q.ampr.org>
From: Phil Karn <karn@unix.ka9q.ampr.org>
To: hfsig@tapr.org
Reply-To: karn@qualcomm.com
In-reply-to: <199610180750.JAA19000@gillespie.ee.ethz.ch> (message from Rolf
	Sommerhalder on Fri, 18 Oct 1996 02:52:00 -0500 (CDT))
Subject: Re: [HFSIG:1670] Re: Why things are the way they are

>I guess that the IS-95/CDMA cellular phone standard is an interesting
>case which maybe in support of my ideas. Phil might want expand on similar
>mechanisms which are applied by his employer to create a new market for CDMA
>(which did not even exist before), and to compete against established GSM
>technology.

The IS-95 CDMA waveforms are described in exacting detail in a public
document with the number, coincidentally enough, "IS-95". :-)

The technology is, however, heavily laced with patents which are sadly
unavoidable in a purely commercial system. I am hoping against hope
that we can avoid these in an open waveform design intended for
amateur use.

Phil

From N0AOT@aol.com Wed Oct 23 09:51:19 1996
Received: from emout08.mail.aol.com (emout08.mx.aol.com [198.81.11.23]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id JAA22664 for <hfsig@tapr.org>; Wed, 23 Oct 1996 09:51:17 -0500 (CDT)
From: N0AOT@aol.com
Received: by emout08.mail.aol.com (8.6.12/8.6.12) id KAA08867 for hfsig@tapr.org; Wed, 23 Oct 1996 10:50:46 -0400
Date: Wed, 23 Oct 1996 10:50:46 -0400
Message-ID: <961023105045_216662458@emout08.mail.aol.com>
To: hfsig@tapr.org
Subject: Re: [HFSIG:1582] Re: Development Environment

Hi All--

Suggestion:  If phase reference and clock information are really the critical
part of all this, why not take the easy way out and use a world-wide external
reference for the clock information, such as could be derived from a GPS
signal? 

Tom Clark has already done most of the work on this with his Totally Accurate
Clock project. It would mean that a modem would have to incorporate a GPS
engine, but what they heck, they are getting cheap and it sure seems like it
would solve  lots of implementation problems!

--Bob (n0aot@amsat.org)
 

>>The real trick is in deriving the incoming carrier phase reference.
>>And doing this well is a real bitch (if not downright impossible) at
>>low data rates on channels with the slightest bit of unpredictable
>>movement (satellite or ionospheric motion, etc).
>
>Yes, precisely.  THe "block" on the "simulator" just used the clock from the
>transmit side and didn't bother to derive *any* clocks.  It was OK for
>evaluating some things, but not nearly as useful as its price tag would have
>indicated...
>
>Cheers,
>
>Lyle
>
>


From srbible@gnatnet.net Wed Oct 23 17:27:30 1996
Received: from rupe.gnatnet.net (root@rupe.gnatnet.net [206.30.198.8]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id RAA11026; Wed, 23 Oct 1996 17:27:28 -0500 (CDT)
Received: from avatar.eagnet.com (dialup82.gnatnet.net [206.30.198.182]) by rupe.gnatnet.net (8.6.13/8.6.12) with SMTP id SAA31043; Wed, 23 Oct 1996 18:27:44 -0400
Message-Id: <1.5.4.32.19961023222729.0067c0e0@gnatnet.net>
X-Sender: srbible@gnatnet.net
X-Mailer: Windows Eudora Light Version 1.5.4 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 23 Oct 1996 18:27:29 -0400
To: dsp-93@tapr.org, hfsig@tapr.org
From: "Steven R. Bible" <srbible@gnatnet.net>
Subject: Re: [DSP-93:2340] EVM56002 radio interface schematic?

Mark, I am way overdue in getting the DSP Experimenters Web Pages on the
TAPR Web site updated and improved.  I just happen to be working on a
DSP56002EVM page.  It will have the schematic and PCB layouts available in
both PDF and PS format.  Look for the page at 

   http://www.tapr.org/dsp/evm56k

As always, please let me know of any suggestions and comments to improve the
pages.

73,  Steve N7HPR



At 09:11 AM 10/23/96 -0500, you wrote:
>Hello all,
>
>In anticipation of the EVM56002 arrival, I was considering the radio
>interface issue.  Johan, KC7WW, has a schematic of such a beast, but I
>cannot read the file types.  He has posted both the following:
>=======
>Native EVM56002 Applications (KC7WW)
>
>EVMPCB.PLT
>       KC7WW's EVM radio interface schematic in HPGL format.
>EVMPCB.SCH
>       KC7WW's EVM radio interface schematic in ORCAD format.
>
>========
>
>Can anybody on this list make some sort of translation of these into either
>.PDF or .BMP file types so some of us nontechnical types can print the
>schematic?  The files are available at:
>
>ftp://ftp.tapr.org/tapr/SIG/hfsig/upload/evm56k3.zip
>
>
>Thanks,
>
>--------------------------
>Mark L. Hammond [KC4EBR]
>Campbell University
>
>
>

 - Steve, N7HPR
 (n7hpr@tapr.org)

From mburke@llajta.nrc.bolnet.bo Thu Oct 24 00:26:52 1996
Received: from llajta.nrc.bolnet.bo ([166.114.101.11]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id AAA03181; Thu, 24 Oct 1996 00:26:44 -0500 (CDT)
Received: from ns.entel.net ([166.114.102.36]) by llajta.nrc.bolnet.bo (8.7.4/8.7.3) with SMTP id BAA24970; Thu, 24 Oct 1996 01:30:05 +0400
Message-Id: <199610232130.BAA24970@llajta.nrc.bolnet.bo>
Comments: Authenticated sender is <mburke@llajta.nrc.bolnet.bo>
From: "Michael A. Burke" <mburke@llajta.nrc.bolnet.bo>
Organization: BP Associates
To: hfsig@tapr.org
Date: Thu, 24 Oct 1996 01:25:43 -0400
Subject: Linux and Clover?
Reply-to: mburke@llajta.nrc.bolnet.bo
CC: bbssig@tapr.org
X-Confirm-Reading-To: mburke@llajta.nrc.bolnet.bo
X-pmrqc: 1
Return-receipt-to: mburke@llajta.nrc.bolnet.bo
Priority: normal
X-mailer: Pegasus Mail for Win32 (v2.31)

Anyone out there know of any drivers or software which works with the 
HAL Clover boards under Linux?

Mike - cp5vw


... Mike

From karn@qualcomm.com Thu Oct 24 04:34:14 1996
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id EAA12710 for <hfsig@tapr.org>; Thu, 24 Oct 1996 04:34:12 -0500 (CDT)
Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id CAA17287; Thu, 24 Oct 1996 02:33:39 -0700 (PDT)
Date: Thu, 24 Oct 1996 02:33:39 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199610240933.CAA17287@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <961023105045_216662458@emout08.mail.aol.com> (N0AOT@aol.com)
Subject: Re: [HFSIG:1677] Re: Development Environment

>Suggestion:  If phase reference and clock information are really the critical
>part of all this, why not take the easy way out and use a world-wide external
>reference for the clock information, such as could be derived from a GPS
>signal? 

Because the round trip path delay is not known precisely enough, and
it also varies. External GPS-derived timing may be good enough for
symbol timing, if the symbol rate is not too fast and if the
propagation delay can be estimated. It won't work for carrier phase,
though. Even on HF the wavelength is much smaller than the delay
uncertainty.

This is not to say that GPS isn't quite useful as a stable frequency
reference to eliminate one of the sources of uncertainty in the system.
But phase tracking in the modem itself still seems essential.

Phil

From alanb@polecat.sr.hp.com Thu Oct 24 14:58:11 1996
Received: from paloalto.access.hp.com (daemon@paloalto.access.hp.com [15.254.56.2]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id OAA02468 for <hfsig@tapr.org>; Thu, 24 Oct 1996 14:57:53 -0500 (CDT)
Received: from srmail.sr.hp.com by paloalto.access.hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA005237069; Thu, 24 Oct 1996 12:57:50 -0700
Received: from polecat.sr.hp.com (algae.sr.hp.com) by srmail.sr.hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA045576994; Thu, 24 Oct 1996 12:56:35 -0700
Received: by polecat.sr.hp.com
	(1.37.109.16/15.5+ECS 3.3) id AA277236993; Thu, 24 Oct 1996 12:56:33 -0700
From: Alan Bloom <alanb@polecat.sr.hp.com>
Message-Id: <199610241956.AA277236993@polecat.sr.hp.com>
Subject: GPS for clock recovery
To: hfsig@tapr.org
Date: Thu, 24 Oct 1996 12:56:33 -0800 (PDT)
X-Mailer: ELM [version 2.4 PL21]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Phil Karn <karn@qualcomm.com> wrote:

>>Suggestion:  If phase reference and clock information are really the critical
>>part of all this, why not take the easy way out and use a world-wide external
>>reference for the clock information, such as could be derived from a GPS
>>signal? 
>
>Because the round trip path delay is not known precisely enough, and
>it also varies. 

The path delay between satellite and GPS receiver is compensated for by
the clever algorithms in the GPS unit (using timing data from several
satellites.)  The delay between receiver and transmitter might be a 
problem, however.

>External GPS-derived timing may be good enough for
>symbol timing, if the symbol rate is not too fast and if the
>propagation delay can be estimated. 

Seems like the GPS timing accuracy should be fine.  If the GPS receiver 
can give position to within 100 meters, I assume it must be capable of 
timing accuracy on the order of 100/c = 333 ns, which would be plenty 
good enough for the symbol rates used on HF.

>It won't work for carrier phase,
>though. Even on HF the wavelength is much smaller than the delay
>uncertainty.

Yes, the delay uncertainty between the HF transmitter and receiver is
not generally known and varies (usually slowly) from time to time with 
changes in propagation conditions.  But it seems like there ought to be 
a way around that problem without having to do a full-fledged clock 
recovery in the demodulator.

>This is not to say that GPS isn't quite useful as a stable frequency
>reference to eliminate one of the sources of uncertainty in the system.
>But phase tracking in the modem itself still seems essential.

I know that Tom Clark W3IWI of AMSAT (and NASA) has been working on these
types of questions.  His GPS-based "TAC" Totally Accurate Clock (or if 
you prefer, Tom A. Clark) unit can give very accurate timing information.  
I emailed him to see if he has any thoughts on the subject.

Alan Bloom N1AL

From karn@qualcomm.com Thu Oct 24 16:45:54 1996
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id QAA06618 for <hfsig@tapr.org>; Thu, 24 Oct 1996 16:45:51 -0500 (CDT)
Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id OAA03883; Thu, 24 Oct 1996 14:45:20 -0700 (PDT)
Date: Thu, 24 Oct 1996 14:45:20 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199610242145.OAA03883@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <199610241956.AA277236993@polecat.sr.hp.com> (message from Alan Bloom on Thu, 24 Oct 1996 15:02:18 -0500 (CDT))
Subject: Re: [HFSIG:1681] GPS for clock recovery

>The path delay between satellite and GPS receiver is compensated for by
>the clever algorithms in the GPS unit (using timing data from several
>satellites.)  The delay between receiver and transmitter might be a 
>problem, however.

Right. Actually the GPS receiver solves a set of simultaneous equations
that solve for time along with location. It's easy to get time accurate
to a microsecond or even considerably less out of an inexpensive receiver.

But as I said, that's not the problem in using GPS as a carrier phase
and/or symbol timing reference in a HF communication system. The round
trip delay simply isn't known accurately enough -- you don't
necessarily know in advance where the other station is, and the
constantly shifting ionosphere makes the delay hard to estimate even
if you do know where the other station is. And in the case of carrier
phase via the ionosphere, it never stays constant.

Good modulation schemes exist that do not require precise knowledge of
carrier phase, such as FSK (all forms) and differentially coherent PSK.
Symbol timing is not that hard to extract from the incoming signal at the
rates typically used on HF. While external reference timing might be
useful at very slow symbol rates, the ionospheric doppler spread sets
a lower limit on symbol rate that makes this less than highly useful on HF.

The main application for GPS symbol synchronization that makes sense
is QRP EME, where the symbol rates are slow enough for this to work
and the round trip distance to the moon can be accurately calibrated
(assuming you know the location of the other station).

Phil

From srbible@gnatnet.net Sat Oct 26 20:11:14 1996
Received: from rupe.gnatnet.net (root@rupe.gnatnet.net [206.30.198.8]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id UAA02291; Sat, 26 Oct 1996 20:11:13 -0500 (CDT)
Received: from avatar.eagnet.com ([199.76.206.84]) by rupe.gnatnet.net (8.6.13/8.6.12) with SMTP id VAA31119; Sat, 26 Oct 1996 21:11:20 -0400
Message-Id: <1.5.4.32.19961026123620.0075ff18@gnatnet.net>
X-Sender: srbible@gnatnet.net
X-Mailer: Windows Eudora Light Version 1.5.4 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 26 Oct 1996 08:36:20 -0400
To: dsp93@tapr.org, hfsig@tapr.org
From: "Steven R. Bible" <srbible@gnatnet.net>
Subject: TAPR DSP56002EVM Web Pages

Hi All, 

I've spent the day refining and adding to the DSP56002EVM web page on the
TAPR Web server.

    http://www.tapr.org/dsp/evm56k/index.html

I've managed to catalog all of the experimenting that has been done on the
EVM.  There's KC7WW, ZS6AWK, and EA2ARU's work featured.  If you know of any
other projects please email me.

With the success of the TAPR group purchase of the EVM, there's going to be
a couple of hundred new experimenters out there.  Hopefully, this page can
be a good starting place for these folks and veterans alike.

As always, suggestions are welcome in improving the pages.

73,

 - Steve, N7HPR
 (n7hpr@tapr.org)

From forrerj@peak.org  Sat Oct 26 23:23:49 1996
Received: from PEAK.ORG (root@PEAK.ORG [198.68.22.17]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id XAA09216 for <hfsig@tapr.org>; Sat, 26 Oct 1996 23:23:47 -0500 (CDT)
Received: from p07.t0.monrotel.com (p05.t0.monrotel.com [198.68.25.38]) by PEAK.ORG (8.6.13/8.6.7) with SMTP id VAA22797 for <hfsig@tapr.org>; Sat, 26 Oct 1996 21:23:55 -0700
Message-Id: <199610270423.VAA22797@PEAK.ORG>
X-Sender: forrerj@peak.org
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 26 Oct 1996 21:24:18 -0800
To: hfsig@tapr.org
From: forrerj@peak.org (Johan Forrer)
Subject: Re: [HFSIG:1683] TAPR DSP56002EVM Web Pages

Hi Steve,


Your efforts are much appreciated.
I may just add that there have been some useful bug fixes and improvements to 
the Leonid OS that folks should know about. Some of these were contributed by 
Doug Braun; the most notable is a way to load the OS into FLASH so that it
boots 
that right away on reset.

When the EVM support group starts up, I'll be happy to post a summary of these
recent additions and improvements.

73's till later

--Johan

P.S. Sorry for not showing much activity lately - things are just hectic.

>Hi All, 
>
>I've spent the day refining and adding to the DSP56002EVM web page on the
>TAPR Web server.
>
>    http://www.tapr.org/dsp/evm56k/index.html
>
>I've managed to catalog all of the experimenting that has been done on the
>EVM.  There's KC7WW, ZS6AWK, and EA2ARU's work featured.  If you know of any
>other projects please email me.
>
>With the success of the TAPR group purchase of the EVM, there's going to be
>a couple of hundred new experimenters out there.  Hopefully, this page can
>be a good starting place for these folks and veterans alike.
>
>As always, suggestions are welcome in improving the pages.
>
>73,
>
> - Steve, N7HPR
> (n7hpr@tapr.org)
>
>

From wd5ivd@tapr.org Sat Oct 26 23:54:21 1996
Received: (from wd5ivd@localhost) by tapr.org (8.7.5/8.7.3/1.9) id XAA11279 for hfsig@tapr.org; Sat, 26 Oct 1996 23:54:21 -0500 (CDT)
From: Greg Jones <wd5ivd@tapr.org>
Message-Id: <199610270454.XAA11279@tapr.org>
Subject: Re: [HFSIG:1684] Re: TAPR DSP56002EVM Web Pages
To: hfsig@tapr.org
Date: Sat, 26 Oct 1996 23:54:20 -0500 (CDT)
In-Reply-To: <199610270423.VAA22797@PEAK.ORG> from "Johan Forrer" at Oct 26, 96 11:29:11 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

> When the EVM support group starts up, I'll be happy to post a summary of these
> recent additions and improvements.

Good news!  It has :-)

You join the DSP@TAPR.ORG list by sending e-mail to

listserv@tapr.org
in the message put
subscribe dsp Your Name (First and Last, Call please)

You can also use the SIG page in www.tapr.org

We should start shipping the first units out next week.  Motorola still owes
us 60+ units to fullfill the order we have here.  They are coming last I
heard.

Anyway -- this should be fun :-)

Cheers - Greg, WD5IVD

